IT’ de availability, yani kullanılabilirlik gerçekten önemlidir. Bir müşterinin erişmeyi beklediği hizmetler çalışmadığında, söz konusu müşteri mutsuz olacaktır. Sonuçta, müşteri neden ihtiyaç duyduğunda IT’ de olmayan bir hizmet için ödeme yapsın? Tabi ki bu nedenle, üzerinde anlaşmaya varılmış bir hizmet kullanılabilirliği ölçütü, çoğu zaman kilit bir performans göstergesidir. Bu göstergelere Key Performance Indicators (KPI) denir.
IT personelleri genellikle kararlaştırılan IT hedefinin karşılandığını görmek için çok sıkı çalışır ve müşterilere rapor verirken hedeflere ulaşıldığını kanıtlayan rakamlar sağlar. IT organizasyonları bunu yapmak için genellikle %99,9 veya buna benzer yüzdeler kullanırlar. Ne yazık ki, bu bazen IT hizmet kuruluşlarının/birimlerinin yüzde ölçüsüne odaklandığı ve gerçek hedeflerini gözden kaçırdığı anlamına gelir. Rakamları tutturmak demek, müşteri memnun etmek demek değildir. Bu nedenle, önce SLA’ deki yüzdeler nasıl tespit edilir buna bir bakalım.
Yüzdeleri Tespit Etme Sorunu
Bu bölüme başlamadan önce bir kaç kısaltma vermem gerekiyor:
AST : Agreed Service Time, Kabul Edilen Servis Süresi
DT : Down Time, Kesinti
IT servislerinin kullanılabilirliğini hesaplamanın en basit yollarından biri iki sayıya bakar. Raporlama boyunca hizmetin kullanılabilir olması gereken süreyi kabul edersiniz. Bu, kararlaştırılan hizmet süresidir (AST, Agreed Service Time). O dönemdeki herhangi bir kesinti süresini (DT, Down Time) ölçersiniz. Kesinti süresini kabul edilen hizmet süresinden uzaklaştırır ve bunu bir yüzdeye dönüştürürsünüz.
Kullanılabilirlik = (AST – DT) / AST x %100 formülü ile hesaplanmaktadır.
AST’ nin 100 saat durumlarda ise;
Kullanılabilirlik = (100-2) / 100 x %100 = %98 ile hesaplanmaktadır.
Buradaki sorun şu ki, bu hesaplamaları gerçekleştirmek ve hesaplamaları yapmak için gereken verileri toplamak yeterince kolay olsa da sonuçta elde ettiğiniz rakamın size ne söylediği gerçekten net değildir. Daha da kötüsünü söyleyeyim; müşterinin bakış açısından, müşteriyi tamamen memnun etmeden aynı zamanda kabul edilmiş hedeflere ulaştığınızı bildiriyor olabilirsiniz. Bu da aslında rakamları tutturduğunuzu, fakat gerçek memnuniyete ulaşmadığınızı ispatlar. Müşteriler, IT servislerinin yalnızca iş süreçlerini doğru bir şekilde desteklediği sürece yüzdelik rakamlarla ilgilenmektedir ve büyük olasılıkla teslim ettiğiniz rakamlarda bu görünmez. Buna dikkat etmek lazım, rakamların doğru olması IT servislerini kullanan her müşterinin memnun kaldığı anlamını taşımıyor.
Kullanılabilirlik (Availability) Hedeflerinin Tanımlanması
Kullanılabilirliği kuruluşunuz ve müşterileriniz için faydalı olacak şekilde ölçmek, belgelemek ve raporlamak istiyorsanız, iki şey yapmanız gerekir. İlk olarak, şartları ve bugünkü durumu anlamak gerek. Bunu yapmak için de müşterilerinizle konuşmanız gerekir. İkincisi, bir dizi pratik konu hakkında çok dikkatli düşünmeniz gerekir: neyi ölçeceksiniz, verilerinizi nasıl toplayacaksınız ve bulgularınızı nasıl belgeleyeceksiniz ve raporlayacaksınız.
Harekete geçmeden önce, müşterilerinizin verimlilik için nelere ihtiyaç duyduğunu ve verimlilik kaybının onlar üzerinde ne gibi etkileri olduğunu bulmanız gerekir. Bu; teknoloji, bütçe ve personel kısıtlamalarını dikkate alan gerçekçi hedefleri kabul etmenizi sağlayacaktır. Başka bir deyişle; neye ihtiyaç duyduklarını anlamanız için ve gerekirse “her zaman kullanılabilir olmasını istiyorum” cümlesinin muhtemelen her zamankinden daha pahalıya mal olacağını anlamalarına yardımcı olmak için müşterilerinizle konuşmanız gerekir.
Konuşmada mükemmel bir başlangıç, kesinti süresinin işe olan etkisidir. İşte sormanız gereken beş soruyu veriyorum:
- İşletmenizin/biriminizin hangi işlevlerinden hangilerinin çalışmama sürelerinden korunmaları çok önemlidir?
- Herhangi bir kesinti süresi işinizi nasıl etkiler?
- Duruş süresi sıklığı işletmenizi nasıl etkiler?
- Duruş süresinin kuruluşunuzun/iş biriminizin üretkenliği üzerinde ne gibi etkileri vardır?
- Duruş süresinin kuruluşunuzun/iş biriminizin müşterileri üzerinde nasıl bir etkisi var?
Bu soruların cevapları, size yukarıda anlattığım ölçümleri yapmakta ilk adımlar için yardımcı olacaktır.
Kritik İş Fonksiyonları
Çoğu IT hizmeti çeşitli iş süreçlerini destekler. Bunlardan bazıları kritik, diğerleri daha az önemlidir. Örneğin; bir muhasebe sisteminde hem faturanın oluşturulması, hem de faturanın e-posta olarak gönderilmesi IT tarafından desteklenebilir. Sistemin fatura oluşturma yeteneği kritik öneme sahiptir, ancak sistem e-postayı geç gönderiyorsa bunun etkisi çok daha düşüktür.
Müşterilerinizle konuşmanız ve işlerinin çeşitli işlevlerinin önemi hakkında bir anlaşmaya varmanız gerekir. Bu işlevlerin her birini birbirine göre kaybetmenin ardından gelen iş etkisini gösteren bir tablo hazırlamanız faydalı olabilir. Önceki örnekten yola çıkarak:
Muhasebe sisteminin fatura oluşturamaması à %100
Oluşturulan faturaların e-posta olarak gitmemesi à %50
Yukarıdaki iki örnek, bize muhasebe hizmetini tasarlarken ve yönetirken asıl eforu nereye odaklayacağımızı söylemektedir.
Süre ve Downtime Sıklığı
Müşterinin işinin durma süresinin sıklığından ve süresinden nasıl etkilendiğini öğrenmeniz gerekir. 100 saat boyunca kullanılabilir olması gereken bir hizmet %98 kullanılabilirliğe sahip olduğunda, bu, iki saat kesinti olduğu anlamına gelir. Ancak bu, iki saatlik tek bir olay veya daha kısa sayıda birden fazla olay anlamına gelebilir. Tek bir uzun olayın veya çok daha kısa olayın göreceli etkisi, işin niteliğine ve iş süreçlerine bağlı olarak farklı olacaktır.
Örneğin, tamamlanması iki gün süren ve herhangi bir kesintiden sonra yeniden başlatılması gereken bir faturalandırma işlemi, her kısa kesintiden ciddi şekilde etkilenir, ancak uzun süren bir kesinti daha az etkilenebilir. Öte yandan, web tabanlı bir alışveriş sitesi bir dakikalık kesintiden etkilenmeyebilir, ancak iki saat sonra gerçekleşecek müşteri kaybı önemli olabilir. Olası etkiyi öğrendikten sonra, müşteriyi gerçekten destekleyecek altyapıyı, uygulamaları ve süreçleri yerleştirmek, anlamlı hedefler belirlemek ve bunları uygun şekilde belgelemenin ve raporlamanın yollarını bulmak için çok daha iyi bir konumdasınız demektir.
Aşağıda, kesinti süresinin etkisinin değiştiği gerçeğini yansıtacak şekilde kullanılabilirliği nasıl ölçebileceğiniz ve belgeleyebileceğinize bir örnek verilmiştir:
| Kesinti Süresi | Maksimum Sıklık |
| 2 dakikaya kadar | Saatte 2 olay Günde 5 olay Haftada 10 olay |
| 2 – 30 dakikaya kadar | Haftada 2 olay Çeyrek başına 6 olay |
| 30dk – 4 saat | Yılda 4 olay |
| 4 – 8 saat | Yılda 1 olay |
Müşterilerinizle çalışmama süresinin sıklığını ve süresini tartışırken böyle bir tablo kullanırsanız, sayıların kullanılabilirlik yüzdesinden çok daha yararlı olması muhtemeldir ve kesinlikle müşterileriniz için daha anlamlı olacaktır.
Downtime (Kesinti) ve Verimlilik
Yüzde kullanılabilirlik oranının, müşterilerle çalışmama süresi sıklığı ve süresi hakkında konuşmak için çok yararlı olmadığını yukarıda da belirtmiştim. Aksine, kesinti süresinin üretkenlik üzerindeki etkisini tartıştığınızda, yüzde etkisi gerçekten çok yararlı bir önlem olabilir.
Çoğu olay tüm kullanıcılar için tam bir hizmet kaybına neden olmaz. Bazı kullanıcılar kesintilerden etkilenmeyebilir, bazılarının ise hiç hizmeti bile yoktur. Bir uçta, herhangi bir hizmete erişemeyen hatalı bir PC’ ye sahip tek bir kullanıcı olabilir. Bunu %100 hizmet kaybı olarak sınıflandırabilirsiniz, ancak bu IT’ yi tamamen gerçekçi olmayan bir hedefle bırakacak ve kullanılabilirliğin adil bir ölçümü olmayacaktır.
IT servislerinin işe olan etkisini ölçmenin yolu, servisler yok iken geçen dakikaların yüzdesini hesaplamaktır. Şimdi bu formülü verelim:
- PotentialUserMinutes değerini hesaplayalım. Bu toplam kullanıcı sayısı, çalıştıkları sürenin kat sayısıdır. Örneğin, 8 saat çalışan 200 çalışanınız varsa, PotentialUserMinutes 200 x 8 x 60 = 96000.
- UserOutageMinutes hesaplayalım. Bu, çalışamayan toplam kullanıcı sayısıdır ve çalışamadıkları süreyle çarpılır. Örneğin, bir olay 200 kişinin 10 dakika çalışmasını engellerse, UserOutageMinutes 2000 olur.
- Yukarıdaki formüle çok benzeyen bir formül kullanarak kullanılabilirlik yüzdesini hesaplayalım.
Kullanılabilirlik = (PotentialUserMinutes – UserOutageMinutes) / PotentialUserMinutes x %100
Yukarıdaki örneğe göre;
Kullanılabilirlik = (9600 – 2000) / 96000 x %100 = %97’ dir.
Kuralları ve teknikleri öğrendiğimize göre ölçme ve raporlamaya artık geçebiliriz. Kullanılabilirlik hedeflerinizi kabul ettikten ve belgeledikten sonra, kullanılabilirliği nasıl ölçüp raporlayabileceğinizin pratik yönlerini düşünmeniz gerekir. Örneğin:
- Neyi ölçeceksiniz?
- Verilerinizi nasıl toplayacaksınız?
- Bulgularınızı nasıl raporlayacaksınız?
Ölçülen Ne Olmalı?
Ölçümlemede; kullanılabilirliği, müşterilerle önceden kararlaştırılmış olan ve hedeflerle karşılaştırılabilecek ve de müşterinin gerçekten ihtiyaç duyduğu şeylerin ortak bir anlayışına dayanan bir şekilde ölçmek ve raporlamak esastır. Hedefler müşteriye anlamlı gelmeli ve IT organizasyonunun/biriminin çabalarının müşterinin iş ihtiyaçlarına destek sağlamaya odaklanmasını sağlamalıdır.
Genellikle, hedefler IT organizasyonu ile müşteri arasında bir hizmet seviyesi sözleşmesinin (SLA) bir parçasını oluşturur – ancak bir SLA’ deki rakamların hedefiniz olmadığına dikkat edin. SLA’ de asıl amaç müşterilerinizin ihtiyaçlarını karşılayan IT servisleri sunmaktır. Rakamlara takılmayın.
Veriler Nasıl Toplanmalı?
Kullanılabilirlik verilerini toplamanın en kısa yolu servis masası/help desk uygulamalarıdır. Servis masası personeli, her olayın iş etkisini ve süresini, olayları yönetmenin rutin bir parçası olarak tanımlar veya tanımlamalıdır. Ölçümleme yaparken bu verileri, olayların süresini ve etkilenen kullanıcı sayısını belirlemek için kullanabilirsiniz. Bu yaklaşım genellikle ucuzdur. Ancak, kullanılabilirlik verilerinin doğruluğu hakkında belirsizliklere yol açabilir. Help desk sistemleri, kullananlar tarafından manipule edimezse belirsizlikler olabildiğince ortadan kaldırılabilir.
Ölçüm Bulgularının Raporlanması
Verileri topladıktan sonra raporu nasıl sunacağımızı düşünmemiz gerekli.
Ölçüm ve raporlamanın genellikle göz ardı edilen bir yönü planlı kapalı kalma süresidir. Kullanılabilirliği nasıl raporlayacağınızı planlarken planlı çalışmama süresini hesaba katmayı unutursanız, servis sunumunuzu yeterince yansıtmayan kullanılabilirlik rakamlarını bildirebilirsiniz. Bu da sizi yalancı durumuna düşürebilir. Bunu istemeyiz.
Planlı çalışmama süresinin yanlışlıkla kullanılabilirlik istatistiklerini etkilemediğinden emin olmanın birkaç yolu vardır. Bunlardan biri, planlı çalışmama süresinin kullanılabilirlik hesaplamalarına dahil edilmeyen belirli bir pencerede gerçekleşmesidir. Diğeri ise planlı çalışmama süresini planlamak. Örneğin, bazı kuruluşlar bir ay önceden planlanan kesinti sürelerini herkese gösterir. SLA’ in planlanan kapalı kalma süresinin nasıl raporlanacağını açıkça tanımlaması önemlidir.
Örneğin, 7 gün 24 saat IT servisi ve %99 oranında kullanılabilirliği kabul eden bir IT organizasyonunu düşünelim. Bu sistemde 8 saatlik bir kesinti olduğunu varsayalım:
- Her hafta kullanılabilirliği bildirirsek, AST 24 x 7 saat = 168 saattir.
- Aylık olarak ölçülen AST (24 x 365) / 12 = 730 saat.
- Üç ayda bir ölçülen AST (24 x 365) / 4 = 2.190 saattir.
Bu sayıları denkleme yerleştirirsek:
Haftalık = %100 x (168-8) / 168 = % 95.2.
Aylık = %100 x (730 – 8) / 730 = %98.9.
Üç aylık =%100 x (2190 – 8) / 2190 = %99.6.
Kullanılabilirlik süreleri ile karşılaşmış oluyoruz. Bu rakamların her biri, IT’ nin kullanılabilirliği için geçerlidir, ancak bunlardan yalnızca biri hedefin karşılandığını göstermektedir. Çünkü %99’ u kabul etmiştik.
Sonuç
Çalıştığım hemen hemen her IT kuruluşu/birimi, hizmetlerinin kullanılabilirliğini ölçer ve raporlar. Ne yazık ki, birçok IT kuruluşu/birimi bir SLA’ deki rakama odaklanmakta ve kararlaştırılan sayıları sunsalar bile müşterilerinin ihtiyaçlarını tamamen karşılayamamaktadırlar.
Bu makalemde Availability (Kullanılabilirlik) rakamlarının nasıl hesaplanacağını anlatmanın yanı sıra, servislerin durumunun nasıl ölçüleceği ve raporlanacağı konusunda bir dizi öneri sundum. Umarım faydalı olur.