BT’nin verdiği söz, arkasındaki en zayıf halkadan güçlü olamaz. Üç belge bu zinciri tanımlar.
- SLA (Hizmet Seviyesi Anlaşması): BT ile iş birimi arasında. “Kritik olaylar 4 saatte çözülür.”
- OLA (Operasyonel Seviye Anlaşması): BT’nin iç ekipleri arasında. “Ağ ekibi kendisine atanan kaydı 1 saatte devralır.”
- UC (Destekleyici Sözleşme): BT ile dış tedarikçi arasında. “Donanım tedarikçisi ertesi iş günü parça getirir.”
Zincir hesabı
SLA’nız 4 saatse ama tedarikçi sözleşmeniz “ertesi iş günü” diyorsa, donanım arızasında SLA’yı tutamazsınız. Bu bir performans sorunu değil, tasarım hatasıdır.
Her SLA maddesi için şu soruyu sorun: bu taahhüdü tutmak için hangi iç ekibe ve hangi tedarikçiye bağımlıyım, onların taahhüdü nedir?
Duraklatma (clock stop) kuralları yazılı olsun
En çok tartışma yaratan konu budur. Kullanıcıdan bilgi beklenirken sayaç duruyor mu? Tedarikçi parça beklerken? Bakım penceresinde?
Yazılı değilse her raporlama döneminde yeniden tartışılır ve rapora güven kalmaz. Kural sade olsun: sayaç yalnızca BT’nin kontrolü dışındaki beklemelerde durur ve duraklatma kaydın içinde gerekçesiyle görünür.
Çözüm süresi mi, yanıt süresi mi?
İkisini ayrı taahhüt edin. Yanıt süresi BT’nin kontrolündedir ve tutulabilir. Çözüm süresi arızanın doğasına bağlıdır. Yalnızca çözüm süresi taahhüt eden SLA’lar, tutulamadıkça anlamsızlaşır.
Ölçüm
Ayda bir üç sayı: SLA uyum oranı, OLA ihlali sayısı (hangi ekipte), UC kaynaklı gecikme sayısı. Üçüncüsü sıfırdan büyükse ve SLA da ihlal ediliyorsa, sorun ekipte değil sözleşmededir — çözüm daha çok çalışmak değil, sözleşmeyi yenilemektir.