Yazılım bakım SLA’sı, fiyat listesinden çok yanıt süresi, kapsam ve ölçülebilir servis seviyelerini netleştiren bir anlaşma çerçevesidir. Bu rehberde KOBİ’lerin bakım paketini belirsizlikten çıkarıp uygulanabilir maddelere dönüştürmesi için adım adım bir yol haritası bulacaksınız.
Yazılım teslim edildikten sonra asıl risk, “bakım var” denilip kapsamın belirsiz bırakılmasıdır. Bir yazılım bakım sla belgesi; neyin ne kadar sürede ele alınacağını, neyin paket dışı kaldığını ve performansın nasıl ölçüleceğini yazılı hale getirir. KOBİ’ler için amaç pahalı bir hukuk metni üretmek değil; operasyonu yönetilebilir kılmaktır.
Bu rehberde bakım paketini fiyat satırlarından ziyade yanıt süresi, öncelik sınıfları, kapsam dışı maddeler ve ölçülebilir servis seviyeleriyle nasıl netleştireceğinizi adım adım ele alıyoruz. Anlaşma imzalamadan önce hangi soruları sormanız gerektiğini de somut örneklerle göreceksiniz.
Yazılım bakım SLA nedir ve ne işe yarar?
SLA (Service Level Agreement), bakım hizmetinin taahhüt edilen seviyesini tanımlayan servis seviyesi anlaşmasıdır. Destek kanalını, öncelik tanımını, ilk yanıt ve çözüm hedeflerini, raporlama biçimini ve ihlal durumunda izlenecek yolu tek belgede toplar.
Bakım sözleşmesi “ne yapılacağını” anlatırken, yazılım bakım SLA’sı “ne kadar sürede ve hangi kalitede yapılacağını” ölçülebilir hale getirir. İkisi çoğu zaman aynı dosyada yer alır; ancak KOBİ’lerde sık görülen hata, yalnızca aylık ücret ve “sınırsız destek” gibi belirsiz ifadelerle yetinmektir.
İyi yazılmış bir SLA şu üç soruya net cevap verir:
- Hangi olay ne kadar sürede ilk yanıt alır?
- Hangi işler paket kapsamındadır, hangileri ayrıca tekliflenir?
- Performans hangi metriklerle ve hangi periyotta raporlanır?
Özel yazılım veya sürekli gelişen bir ürün kullanıyorsanız, bakım SLA’sını yazılım geliştirme sürecinin devamı gibi düşünmek faydalıdır: geliştirme biter, işletme başlar; ölçüm de burada başlar.
SLA’da bulunması gereken temel bölümler
Belgeyi uzun tutmak zorunda değilsiniz. KOBİ ölçeğinde okunabilir, kısa ve uygulanabilir bir yapı genellikle yeterlidir. Aşağıdaki bölümler çoğu yazılım bakım SLA’sında işe yarar:
Taraflar, sistem kapsamı ve iletişim
Hangi uygulamaların, ortamların (canlı, test) ve entegrasyonların kapsama girdiğini yazın. Destek talebinin hangi kanaldan açılacağını, kimlerin yetkili talep sahibi olduğunu ve acil durumda kimin aranacağını netleştirin. Rol belirsizliği, bakımda da gecikme üretir; karar mercilerini net tutmak için yazılım projesi rolleri yaklaşımını bakım tarafına da taşıyabilirsiniz.
Hizmet saatleri ve öncelik sınıfları
“7/24 destek” ifadesi tek başına yeterli değildir. Mesai içi / mesai dışı ayrımı, tatil günleri ve kritik olaylar için ayrı kanal tanımı yapılmalıdır. Öncelik sınıfları (örneğin kritik, yüksek, orta, düşük) iş etkisiyle bağlanmalıdır: “sistem tamamen kullanılamıyor” ile “raporda küçük bir hata var” aynı kuyruğa düşmemelidir.
Yanıt süresi, çözüm hedefi ve geçici çözüm
İlk yanıt süresi ile kalıcı çözüm süresi farklı metriklerdir. Kritik olaylarda geçici çözüm (workaround) süresi de ayrıca tanımlanabilir. Metinlerde “en kısa sürede” yerine ölçülebilir hedefler kullanın; ancak hedefin gerçekçi kapasiteye dayanması gerekir.
Kapsam, kapsam dışı ve değişiklik yönetimi
Güvenlik yamaları, hata düzeltme, izleme, yedek kontrolü ve küçük yapılandırma gibi kalemleri kapsama yazın. Yeni özellik geliştirme, büyük tasarım değişikliği, üçüncü taraf kaynaklı kesinti veya kullanıcı eğitimleri çoğu zaman ayrı iş kalemidir. Kapsam dışı maddeler net yazılmazsa her istek “bakım hakkından” sayılır.
Raporlama, sorumluluklar ve sona erme
Aylık veya dönemsel servis raporu, açık talep sayısı, ihlal kaydı ve planlı bakım pencereleri belgede yer almalıdır. Veri erişimi, yedekleme sorumluluğu ve erişim yetkileri de netleştirilmelidir; aksi halde olay anında kim neyi yapacağını bilemez.
Yanıt süresi ve servis seviyesi maddeleri nasıl yazılır?
Yazılım bakım SLA’sının kalbi, ölçülebilir süre ve kalite maddeleridir. Aşağıdaki tablo, KOBİ’lerin belgede netleştirmesi gereken alanları özetler. Süreler örnek çerçevedir; kendi iş riskinize ve ekip kapasitenize göre belirlenmelidir.
| Öncelik | İş etkisi örneği | Netleştirilecek metrik | Belgede yazılması gereken |
|---|---|---|---|
| Kritik | Canlı sistem tamamen durdu, gelir veya operasyon durdu | İlk yanıt, geçici çözüm, bilgilendirme sıklığı | Kanal, eskalasyon, mesai dışı kuralı |
| Yüksek | Ana akış bozuldu ama kısmi çalışma var | İlk yanıt ve hedef çözüm penceresi | İş birimi onayı ve test sorumluluğu |
| Orta | Önemli ama alternatif yol var | Yanıt ve planlı çözüm tarihi | Sprint / bakım penceresi ilişkisi |
| Düşük | İyileştirme, kozmetik hata, soru | Sıralama kuralı ve geri bildirim süresi | Kapsam içi / proje ayrımı |
Metrik yazarken şu ayrımı koruyun:
- İlk yanıt süresi: Talebin alındığının ve önceliğin teyit edildiği süre.
- Geçici çözüm süresi: İşin devam etmesini sağlayan geçici müdahale.
- Kalıcı çözüm hedefi: Kök nedenin giderilmesi için hedef pencere; her olayda garanti gibi değil, ölçülen hedef gibi kurgulanmalıdır.
- Uygunluk oranı: Dönem içinde hedeflenen yanıtlara ne ölçüde uyulduğu.
Ölçüm kuralı da yazılmalıdır. Süre, talep kaydının açıldığı andan mı, eksik bilgi tamamlandıktan sonra mı başlar? Müşteri onayı veya test ortamı erişimi beklenirken süre durur mu? Bu detaylar yazılmazsa dönem sonunda her iki taraf da haklı hisseder ve anlaşmazlık büyür.
Kapsam dışı maddeleri netleştirmek neden kritik?
KOBİ’lerde bakım anlaşmalarının en sık bozulduğu yer kapsam dışıdır. “Küçük bir ek ekran”, “yeni bir rapor”, “farklı bir entegrasyon” talepleri birikir; ekip hata düzeltmeye ayıracağı zamanı özellik geliştirmeye harcar. Sonuçta hem güvenlik güncellemeleri aksar hem de taraflar hayal kırıklığı yaşar.
Kapsam dışı listesini düşmanca değil, şeffaf yazın. Amaç reddetmek değil; işi doğru kovaya koymaktır. Tipik ayrım şöyle kurulabilir:
- Kapsam içi: Hata düzeltme, güvenlik yamaları, performans bozulmalarının incelenmesi, yedek ve izleme kontrolleri, küçük yapılandırma.
- Ayrı teklif / proje: Yeni modül, yeni entegrasyon, büyük arayüz değişikliği, veri migrasyonu, kapsamlı eğitim.
- Müşteri sorumluluğu: Son kullanıcı cihaz sorunları, yetkisiz müdahale, barındırma sağlayıcısı kesintileri (sorumluluk sınırı net yazılmalı).
Güvenlik başlığı özellikle ayrı ele alınmalıdır. Yetkisiz erişim denemeleri, bağımlılık güncellemeleri ve erişim yönetimi gibi konular bakımın parçası olabilir; ancak güvenlik olgunluğu için daha geniş bir kontrol çerçevesi gerekir. Bu noktada uygulama güvenliği kontrol listesi bakım maddelerini tamamlayan iyi bir referans sunar.
KOBİ’ler için yazılım bakım SLA yazım adımları
Belgeyi sıfırdan uzun uzun yazmak yerine şu sırayla ilerleyin. Amaç, yasal süsten önce operasyonel netlik kurmaktır.
1. İş etkisi haritası çıkarın
Hangi ekran veya süreç bozulursa satış, tahsilat, sevkiyat ya da saha operasyonu durur? Kritik akışları listeleyin. SLA öncelikleri teknik etiketle değil, iş etkisiyle tanımlanmalıdır.
2. Destek modelini sadeleştirin
Tek kanal seçin: e-posta, ticket aracı veya tanımlı form. Herkesin her yerden yazdığı bir modelde süre ölçmek imkânsızdır. Yetkili talep sahiplerini sınırlayın; aksi halde aynı olay farklı kişilerden çoğalır.
3. Öncelik ve süre matrisini yazın
Dört seviyeli basit bir matris çoğu KOBİ için yeterlidir. Her seviye için ilk yanıt, bilgilendirme sıklığı ve çözüm hedefi alanlarını doldurun. “Hemen” ve “öncelikli” gibi kelimeleri metrik haline getirin.
4. Kapsam / kapsam dışı listesini iki sütun yapın
Tek cümlelik belirsiz kapsamlardan kaçının. “Bakım ve destek hizmetleri” yerine yapılacak ve yapılmayacak işleri maddeler halinde yazın. Yeni geliştirmelerin change request ile yönetileceğini belirtin.
5. Ölçüm, rapor ve gözden geçirme döngüsü kurun
Aylık kısa rapor: açılan / kapanan talepler, öncelik dağılımı, hedefe uyum, tekrarlayan kök nedenler. Üç ayda bir SLA gözden geçirmesi planlayın. Sistem büyüdükçe veya kullanıcı sayısı arttıkça aynı maddeler yetersiz kalabilir.
6. Eskalasyon ve bağımlılıkları ekleyin
Üçüncü taraf API, ödeme altyapısı, barındırma veya lisans bağımlılıkları olay süresini etkiler. Hangisinin kimin sorumluluğunda olduğunu yazın. KepezWeb gibi ekiplerle çalışırken bile erişim, onay ve test sorumluluğu müşteri tarafında kalabilir; bu sınır net olmalıdır.
Sık yapılan hatalar ve daha iyi alternatifleri
Aşağıdaki hatalar, yazılım bakım SLA belgelerinde tekrar tekrar görünür:
- “Sınırsız destek” vaadi: Sınırsız talep, sınırsız kapsam demektir. Alternatif: öncelik bazlı kotalar veya kapsam içi / dışı ayrımı.
- Yalnızca fiyat odaklı paket: Paket adı ve ücret yazılır, servis seviyesi yazılmaz. Alternatif: ücretin yanında yanıt matrisi ve rapor yükümlülüğü.
- Tek süre her olay için: Her şeye aynı süre koymak ya gerçek dışıdır ya da kritik olayları yavaşlatır. Alternatif: iş etkisine göre kademeli hedefler.
- Ölçüm kuralı eksikliği: Süre ne zaman başlar, ne zaman durur belli değildir. Alternatif: bekleme durumlarını (bilgi, onay, erişim) tanımlayın.
- Güvenlik ve yedeklemenin atlanması: Yalnızca “hata gelince müdahale” modeli, önleyici bakımı unutturur. Alternatif: planlı güncelleme ve kontrol maddeleri ekleyin.
Özel yazılımda bakım, çoğu zaman ürün yaşam döngüsünün parçasıdır. Küçük ama sık iyileştirmeler yapıyorsanız bakım ile geliştirme sınırını net tutmak, hem bütçeyi hem kaliteyi korur. Bu ayrımı kurarken özel PHP/MySQL yazılım gibi sürekli yaşayan sistemlerde değişiklik yönetiminin neden kritik olduğunu da göz önünde bulundurun.
Uygulanabilir bir SLA taslağı için kontrol listesi
Belgeyi imzaya göndermeden önce şu kontrol listesini geçin:
- Kapsamdaki uygulamalar, ortamlar ve entegrasyonlar tek tek yazıldı mı?
- Destek kanalı, yetkili kişiler ve çalışma saatleri net mi?
- Öncelik tanımları iş etkisiyle mi, yoksa yalnızca “acil” kelimesiyle mi kuruldu?
- İlk yanıt, geçici çözüm ve kalıcı çözüm ayrı mı ele alındı?
- Kapsam dışı işler ve ek teklif süreci yazıldı mı?
- Süre ölçümünün başlangıç / durma kuralları var mı?
- Rapor periyodu ve gözden geçirme tarihi belirlendi mi?
- Üçüncü taraf bağımlılıkları ve müşteri sorumlulukları ayrıldı mı?
- Eskalasyon basamakları anlaşılır mı?
- Taraflar belgenin hangi sürümünün geçerli olduğunu biliyor mu?
Bu liste tamamsa elinizdeki metin yalnızca bir teklif eki değil, işletilebilir bir operasyon sözleşmesidir. KepezWeb yaklaşımında da hedef aynıdır: bakım ilişkisini belirsiz vaatlerden çıkarıp ölçülebilir hizmet disiplinine oturtmak.
Sıkça Sorulan Sorular
Yazılım bakım SLA’sı ile bakım sözleşmesi aynı şey midir?
Hayır. Bakım sözleşmesi hizmetin genel çerçevesini ve ticari koşullarını koyar; yazılım bakım SLA’sı ise yanıt süresi, öncelik, kapsam ve ölçüm gibi servis seviyesi maddelerini detaylandırır. Pratikte çoğu KOBİ’de ikisi tek belgede birleşir, ancak içerik olarak farklı işlev görürler.
KOBİ’ler için SLA çok mu karmaşık olur?
Gerekmez. Dört öncelik seviyesi, net kapsam listesi, destek kanalı ve aylık kısa rapor çoğu senaryoda yeterlidir. Karmaşıklık, uzun hukuk dilinden değil; belirsiz vaatlerden doğar.
Yanıt süresi yazmak çözüm garantisi midir?
Hayır. Yanıt süresi, talebin ele alınmaya başlandığı süreyi ifade eder. Kalıcı çözüm; kök neden, üçüncü taraf bağımlılığı ve test onayı gibi etkenlere bağlıdır. Bu yüzden ilk yanıt, geçici çözüm ve kalıcı çözüm ayrı yazılmalıdır.
Yeni özellik talepleri bakım SLA’sına girer mi?
Genelde hayır. Hata düzeltme ve güvenlik yamaları bakım kapsamına yakınken yeni özellikler ayrı kapsam ve teklif gerektirir. Belgede bu ayrım yoksa her geliştirme talebi bakım hakkına dönüşebilir.
SLA ne sıklıkla gözden geçirilmelidir?
Sistem kullanımı, kullanıcı sayısı veya entegrasyonlar değiştiğinde gözden geçirme gerekir. Birçok KOBİ için dönemsel, örneğin üç ayda bir yapılan kısa bir değerlendirme yeterli bir ritim sağlar; kritik olay sonrası da revizyon düşünülmelidir.
Bakım paketiniz hâlâ yalnızca fiyat satırlarından oluşuyorsa, bir sonraki adım yanıt süresi, kapsam dışı maddeler ve ölçülebilir servis seviyelerini yazılı hale getirmektir. İhtiyacınıza uygun bakım ve yazılım desteği çerçevesini netleştirmek için teklif al sayfasından KepezWeb ile iletişime geçebilirsiniz.
