SLA sözleşmesi

"Teknik destek iyi çalışıyor" gibi belirsiz ifadeler yerine, bir SLA net sınırlar belirler: hizmet sağlayıcının bir talebi ne kadar hızlı ele alacağı, kritik bir kesintinin giderilmesinin ne kadar süreceği ve hizmetin ne kadar süreyle erişilebilir olması gerektiği (çalışma süresi).

Bir SLA, hizmet sağlayıcı ile hizmet alıcı arasındaki anlaşmayı kaydeder:

• sağlayıcı: BT departmanı, bir dış kaynak şirketi, bir bulut hizmet sağlayıcısı, tesis yönetimi;
• alıcı: bir iş birimi, kurumsal bir müşteri, bireysel bir kullanıcı.

Bir SLA, nadiren bağımsız bir yasal sözleşme olarak bulunur. Genellikle bir hizmet sözleşmesinin eki veya hizmet ekipleri için bir iç politikadır. Bir SLA'nın gücü, ölçülebilirliğinde yatmaktadır: her parametre, günlükler ve raporlar ile doğrulanabilir.

SLA Türleri

Hizmet yönetimi uygulamalarında, BT alanında üç ana SLA türü bulunmaktadır:

1. Hizmet tabanlı SLA. Belirli bir hizmetin tüm kullanıcıları için tekbir anlaşma. Örneğin, kurumsal e-posta için bir SLA: kurallar, bir yönetici ve CEO için aynıdır.
2. Müşteri tabanlı SLA. Belirli bir müşteriye (veya departmana) sağlanan tüm hizmetleri kapsayan bir anlaşmadır. Örneğin, bir VIP müşteriye, temel plandaki kullanıcılara göre daha sıkı olay müdahale süreleri sunulur.
3. Çok seviyeli SLA. Seviyelere ayrılmış, daha karmaşıkbir format. Örneğin: kurumsal seviye (tüm çalışanlar için genel kurallar), müşteri seviyesi (belirli bir departman için ek garantiler) ve hizmet seviyesi (iş açısından kritik bir ERP sistemi için belirli ölçütler).

SLA, OLA ve UC: Aralarındaki fark nedir?

ITIL'de (BT Altyapı Kütüphanesi), bir Hizmet Seviyesi Anlaşması her zaman diğer iki tür anlaşma ile birlikte gelir. Bu anlaşmalar, sorumluluk zincirinin tamamını kapsayacak şekilde birlikte çalışır.

• SLA (Hizmet Seviyesi Anlaşması) — BT ile işletme (veya bir sağlayıcı ile müşteri) arasında yapılan bir anlaşmadır. Müşteri, yalnızca bu belgede belirtilen nihai sonuçla ilgilenir;
• OLA (Operasyonel Seviye Anlaşması) — sağlayıcının organizasyonu içindeki ekipler arasında yapılan bir anlaşmadır. Örneğin, birinci destek hattı karmaşık bir olayı 15 dakika içinde ikinci destek hattına iletmeli ve ikinci destek hattı bir saat içinde yanıt vermelidir. Müşteri bu belgeyi asla görmez, ancak OLA’lara uyulmadığı takdirde sağlayıcı SLA’yı yerine getiremez;
• UC (Temel Sözleşme) — harici bir tedarikçi veya alt yüklenici ile yapılan bir sözleşmedir. Örneğin, SLA müşteriye bir sunucunun kullanılabilir olacağını garanti eder, ancak sunucunun kendisi bir UC kapsamında bir veri merkezi tarafından sağlanır. UC’nin şartları, SLA’nın şartlarından daha zayıf olmamalıdır.

Neden bir SLA'ya ihtiyacınız var?

Hizmet seviyesi anlaşmasının devreye alınması, birçok kritik iş sorununu aynı anda çözer:

1. Beklentilerin yönetimi. Bir SLA, neyin normal kabul edileceğini açıkça tanımlar ve abartılı talepleri ortadan kaldırır.
2. Objektif kalite değerlendirmesi. SLAsayesinde , "çok yavaş çalışıyorsunuz" argümanı yapıcı bir hale gelir: "Bu ay 100 biletten 15'inde yanıt süresini kaçırdınız".
3. İşlerin önceliklendirilmesi. Servis masası temsilcileri, hangi bilete önce müdahale etmeleri gerektiğini bilir. Çalışmayan bir sunucu (SLA kapsamında kritik öncelikli), bozuk bir yazıcıdan (düşük öncelikli) önce onarılır.
4. Riski azaltma. SLA’da belirtilencezalar , sağlayıcının altyapıyı çalışır durumda tutması için motivasyon sağlar.

SLA’ları kimler kullanır?

Tarihsel olarak bu terim, BT sektöründen (ITIL/ITSM standartları) gelmiştir; ancak günümüzde hizmet seviyesi anlaşması, iç veya dış hizmetlerin bulunduğu her yerde kullanılmaktadır:

• BT ve telekomünikasyon: bulut sağlayıcıları (sunucu kullanılabilirliği garantileri), yazılım geliştiriciler, teknik destek ekipleri;
• B2B dış kaynak kullanımı: muhasebe hizmetleri, temizlik, güvenlik, lojistik;
• şirket içi ortak hizmet merkezleri: İK yönetimi (İK'nın bir izin talebini ne kadar sürede işleme alması gerektiği), hukuki destek (bir avukatın bir sözleşmeyi incelemesi için kaç günü olduğu).

SLA yapısı: bir anlaşmanın içeriği

İyi yazılmış bir belge, belirsizliğe yer bırakmamalıdır. Standart bir SLA yapısı şunları içerir:

1. Hizmet tanımı. Tam olarak ne sunulmaktadır? Hizmetin ayrıntılı açıklaması (örneğin, "İşyeri desteği").
2. Hizmet saatleri. Hizmetne zaman sunulur? (örneğin, 7/24 veya iş günleri 09:00–18:00 arası).
3. Olay ve öncelik matrisi. Taleplerin nasıl sınıflandırıldığı ("Kritik"ten "Düşük"e kadar).
4. Hedef metrikler. Spesifik rakamlar: yanıt süresi, çözüm süresi, kullanılabilirlik yüzdesi.
5. Tarafların sorumlulukları. Müşterinin yapmasıgerekenler (örneğin, zamanında erişim izni vermek) ve sağlayıcının yapması gerekenler.
6. Cezalar ve teşvikler. Metriklerin karşılanmaması durumunda uygulanacak cezalar (genellikle hizmet ücretinin belirli bir yüzdesi) ve daha nadiren, metriklerin aşılması durumunda verilecek bonuslar.
7. Raporlama ve gözden geçirme prosedürü. SLA raporlarınınne sıklıkla hazırlandığı ve belgenin hangi koşullarda değiştirilebileceği.

Temel hizmet seviyesi ölçütleri

Hizmet kalitesi, SLA göstergeleri kullanılarak kontrol edilir. En yaygın olanları şunlardır:

• yanıt süresi: bir biletin gönderilmesinden, bir temsilcinin bunu almasına (veya müşteriye yanıt vermesine) kadargeçen süre ;
• çözüm süresi: biletin oluşturulmasından sorunun tamamen çözülmesine kadar geçen süre;
• MTTR (Ortalama Geri Dönüş/Çözüm Süresi): bir arızadan sonra hizmetin yeniden sağlanması için geçen ortalama süre;
• kullanılabilirlik (çalışma süresi): hizmetin tam olarak çalışır durumda olduğu süreninyüzdesi (meşhur "dokuzlar", örneğin %99,99);
• FCR (İlk Temas Çözüm Oranı): Bir temsilcinin, biletleri diğer destek hatlarına aktarmadan ilk temas sırasında çözdüğü biletlerin oranı.

SLA nasıl yazılır: adım adım

Çekmecede tozlanmak yerine, gerçekten işe yarayan bir SLA'yı beş adımda yazabilirsiniz.

Adım 1. Hizmet kataloğunuzu tanımlayın. Yaptığınız işlerin eksiksiz bir listesini hazırlayın. "BT operasyonlarının sağlanması" gibi genel bir ifade kullanmayın; "Kurumsal e-posta desteği", "Bilgisayar onarımı" gibi somut ifadeler kullanın.

Adım 2. Talepleri öncelik sırasına koyun. Kritik bir olayın (web sitesinin çökmesi) bir hizmet talebinden (birinin yeni bir fareye ihtiyacı olması) nasıl farklı olduğunuaçıklayın .

Adım 3. Gerçekçi ölçütler belirleyin. Vardiyada sadece bir mühendis varsa 5 dakikalık yanıt süresibelirlemeyin . Geçmiş verilere dayanın. Ölçütler ölçülebilir ve ulaşılabilir olmalıdır.

Adım 4. Sorumluluklar üzerinde anlaşın. İşletme veya müşteri ile cezalarıgörüşün . Bu cezalar, hizmetin maliyetiyle orantılı olmalıdır.

Adım 5. Hizmet masanızdaki kuralları yapılandırın. Bir SLA, kronometreyle takip eden bir kişi tarafından izleniyorsa hiçbir işe yaramaz. Tüm ölçütler, BT sisteminizde otomatik olarak izlenmelidir.

SLA uyumluluğunun izlenmesi

SLA performansını manuel olarak (Excel'de veya e-posta yoluyla) takip etmek, hatalara ve müşteri ile anlaşmazlıklara yol açar. Süreci otomatikleştirmek için kuruluşlar, mimarisine Hizmet Seviyesi Yönetimi (SLM) uygulaması entegre edilmiş hizmet masası sistemlerini kullanır.

Hizmet yönetim sistemlerinde (örneğin, SimpleOne ITSM), metrikler otomatik olarak izlenir:

• yapılandırılabilir göstergeler. Sistem, sadece bir zamanlayıcıyı başlatmaktan daha fazlasını yapar. Zamanlayıcının ne zaman başlaması, ne zaman duraklatılması (örneğin, kullanıcının yanıt vermesini beklerken) ve ne zaman durdurulması gerektiğine dair net koşullar tanımlarsınız;

• widget'lar aracılığıyla görselleştirme. Temsilcilerin son tarihleri akıllarında tutmalarına gerek kalmaz. Bilet formunda yer alan özel bir widget, her bir hedef metrik (SLO — Hizmet Seviyesi Hedefleri) için son tarihe kadar gerçek zamanlı geri sayımı gösterir;
• otomatik eylemler ve eskalasyonlar. Yanıt veya çözüm süresi kritik bir eşiğeyaklaşırsa (SLA ihlali riski), sistem biletin önceliğini otomatik olarak değiştirebilir, onu kuyruğun en başına taşıyabilir veya vardiya sorumlusunu bilgilendirerek müdahale etmesini sağlayabilir;
• tek bir sözleşme deposu. Onaylanmış tüm gereksinimler ve anlaşmalar (SLA’lar, OLA’lar, temel sözleşmeler) sistemde depolanır ve hizmet portföyündeki belirli hizmetlere bağlanır. Bu, anlaşmazlıkları ortadan kaldırır: ayın sonunda platform, somut sistem günlüklerine dayalı olarak her müşteri için şeffaf raporlar oluşturur;
• trafik ışığı dengeli puan kartları — KPI'ların ve metriklerin görsel yönetimi için bir SimpleOne platform aracıdır. Renk kodlu sonuçlar içeren özet gösterge panelleri oluşturmanıza ve sapmaları hızlıca tespit etmenize olanak tanır.

Yaygın SLA uygulama hataları

1. Sırf SLA olsun diye SLA. Anlaşma, karmaşık hukuki dilde yazılır ve bir kenara kaldırılır; destek hizmetleri ise “ne olursa olsun” şekilde yürütülür.
2. Gerçekçi olmayan hedefler (karpuz SLA'sı). Sağlayıcı, bunu gerçekleştirecek personel veya altyapı olmadan %99,99 çalışma süresi ve 10 dakikalık olay çözümü vaat etmiştir. Raporların hepsi "yeşil" (karpuzun kabuğu) iken, müşteriler öfkelidir (iç kısım kırmızı).
3. İşletmeyle bağlantısı olmayan metrikler. SLA, "sunucu kullanılabilirliğini" kapsıyor ancak "faturalandırma kullanılabilirliğini" kapsamıyor. Sunucu çalışıyor, ancak müşteriler ödeme yapamıyor. İşletme sunucuyla ilgilenmiyor; ihtiyacı olan şey hizmet.
4. OLA’ları ve UC’leri göz ardı etmek. Müşterinin sorununu 2 saat içinde çözeceğinize sözverdiniz (SLA), ancak harici tedarikçinizin sözleşmesi, arızalı bir sabit diski yalnızca 24 saat içinde değiştirmesini gerektiriyor (UC). Kaçınılmaz olarak bu süreyi aşacaksınız.

Özet

SLA nedir? Müşteri ile sağlayıcı arasındaki ilişkide öngörülebilirliğin garantisidir.

Üzerinde anlaşmaya varılmış bir belgenin olması, anlaşmazlıklardan duygusal unsurları ortadan kaldırır: Taraflar, kimi suçlayacaklarını aramak yerine sorumluluk matrisini açar ve rakamlara bakar. Ancak bir SLA, yalnızca doğru otomasyon araçlarıyla birlikte işe yarar — bir ITSM sistemi olmadan, taahhütleri gerçek zamanlı olarak izlemek pratik olarak imkansızdır.