Yazılım Bakım ve Destek Sözleşmesi (SLA) Nedir? Kapsam, Süreler ve Ücret Rehberi

Yazılım canlıya çıktı, herkes memnun. Üç hafta sonra bir sabah sipariş ekranı açılmıyor, aradığınız kişi ne zaman döneceğini bilmiyor ve "bu garanti kapsamında mı, ayrı ücretli mi?" sorusunun cevabı hiçbir yerde yazılı değil. Yazılım bakım ve destek sözleşmesi, yazılım teslim edildikten sonra neyin, kim tarafından, ne kadar sürede ve hangi ücretle yapılacağını baştan yazıya geçiren sözleşmedir; içindeki hizmet seviyesi taahhüdüne de SLA (Service Level Agreement) denir.

Bu rehberde bakım ve destek sözleşmesinin ne olduğunu, bakım türlerini, SLA'nın neleri kapsadığını, çalışma süresinin (uptime) nasıl hesaplandığını, bakım ücretinin nasıl belirlendiğini, sözleşmede bulunması gereken maddeleri, destek taleplerinin nasıl yönetildiğini ve neyin kapsam dışı kaldığını anlatıyoruz. Örnek süre ve tutarlar temsilîdir; gerçek taahhütler sözleşmeye göre değişir. Yazı hukuki tavsiye değildir; ayrıntılar için hukuk danışmanınıza başvurun.

Yazılım Bakım ve Destek Sözleşmesi Nedir?

Yazılım bakım ve destek sözleşmesi, yayından sonra yazılımın çalışır, güvenli ve güncel kalması için yapılacak işleri, bu işlerin süre ve ücretini tanımlayan sözleşmedir. Garanti süresi, teslimden sonra çıkan hataların ücretsiz giderildiği kısa bir dönemdir; bakım sözleşmesi ise garanti bittikten sonra da süren düzenli hizmettir.

Sözleşme genellikle üç bölümden oluşur: kapsam (hangi işler yapılır), hizmet seviyesi (ne kadar sürede yapılır) ve ticari koşullar (ücret, süre, fesih). Özel yazılım projelerinde bakım ve destek kapsamını projenin başında belirlemek, sonradan çıkacak tartışmaları önler.

Okumanızı öneririz: Özel yazılım nasıl yaptırılır? Firma seçimi, teklif, sözleşme ve ödeme planı rehberi

Yazılım Bakımı Hangi Türlerden Oluşur?

Dört bakım türü vardır ve bir sözleşme hangilerini kapsadığını açıkça yazmalıdır. "Bakım" kelimesi yalnızca hata düzeltmeyi anlatıyorsa, diğer üçü için ayrı iş ve ayrı bütçe gerekir.

Çoğu bakım sözleşmesi ilk üçünü kapsar; yeni özellikler genellikle ayrı bir iş olarak fiyatlanır. Hangi talebin hangi kategoriye girdiği sözleşmede örneklerle açıklanırsa belirsizlik kalmaz.

SLA Nedir, Neleri Kapsar?

SLA, hizmetin hangi seviyede sunulacağını sayılarla taahhüt eden bölümdür. Dört ölçü öne çıkar: destek saatleri, yanıt süresi, çözüm hedefi ve çalışma süresi.

• Destek saatleri ve kanallar: Hangi gün ve saatlerde, hangi kanaldan (e-posta, telefon, talep sistemi) destek verilir?
• Yanıt süresi: Talep açıldıktan sonra ilk geri dönüşün süresi.
• Çözüm hedefi: Sorunun giderilmesi için hedeflenen süre; öncelik seviyesine göre değişir.
• Çalışma süresi (uptime): Sistemin belirli bir dönemde erişilebilir olduğu sürenin oranı.

Süreler, sorunun etkisine göre öncelik seviyelerine bağlanır. Örnek bir öncelik tablosu (temsilî süreler):

Bu süreler yalnızca bir örnektir; gerçek değerler sistemin kritikliğine ve bütçeye göre pazarlıkla belirlenir. Yanıt süresi ile çözüm süresi aynı şey değildir: yanıt "talebinizi aldık, ilgileniyoruz" demektir, çözüm sorunun giderilmesidir.

Çalışma Süresi (Uptime) Nasıl Hesaplanır?

Çalışma süresi, sistemin toplam süre içinde ne kadarında erişilebilir olduğunu yüzde olarak gösterir. Yüzde ne kadar yüksekse, izin verilen kesinti o kadar azdır.

Örnek: 30 günlük bir ay 30 × 24 × 60 = 43.200 dakikadır. Taahhüt %99,9 ise izin verilen kesinti 43.200 × 0,001 = 43,2 dakika, %99,5 ise 43.200 × 0,005 = 216 dakika (3 saat 36 dakika), %99 ise 43.200 × 0,01 = 432 dakika (7,2 saat) olur.

Sözleşmede kesintinin nasıl ölçüleceği de yazılmalıdır: planlı bakım penceresi sayılacak mı, dış servis kaynaklı kesintiler (örneğin ödeme sağlayıcısı) dahil mi? Bu tanımlar olmadan yüzde tek başına bir anlam taşımaz.

Bakım Ücreti Nasıl Belirlenir?

Üç yaygın model vardır: geliştirme bedelinin yüzdesi, sabit aylık ücret ve saat paketi. Hangisinin uygun olduğu, yazılımın ne kadar değişeceğine ve destek yoğunluğuna bağlıdır.

Örnek (temsilî): geliştirme bedeli ₺657.000 olan bir yazılım için yıllık bakım %15 alınırsa 657.000 × 0,15 = ₺98.550 eder. Bu tutarın neleri kapsadığı, yani kaç saatlik iş, hangi öncelik seviyeleri ve hangi destek saatleri içerdiği sözleşmede yazılı olmalıdır. Yüzdeyi tek başına karşılaştırmak yanıltır; iki teklifteki yüzde aynıysa bile kapsamları çok farklı olabilir.

Okumanızı öneririz: Yazılım projesi maliyeti nasıl hesaplanır?

Bakım ve Destek Sözleşmesinde Hangi Maddeler Bulunmalıdır?

Sekiz madde, bakım sözleşmelerinde en sık tartışma çıkan alanlardır. Ayrıntılarını hukuk danışmanınızla netleştirin.

Hizmet seviyesi tutmadığında ne olacağı da netleşmelidir: hizmet kredisi, ücret indirimi ya da fesih hakkı gibi sonuçlar sözleşmede açıkça yazılırsa SLA bir temenni olmaktan çıkar.

Destek Talepleri Nasıl Açılır ve Yönetilir?

Destek tek bir kanaldan ve kayıt altında yürütülmelidir. Telefonla, mesajla ve e-postayla ayrı ayrı iletilen talepler kaybolur ve süre ölçülemez.

1. Talep açılır: Kullanıcı sorunu, ekran görüntüsü ve adımlarıyla birlikte talep sistemine iletir.
2. Öncelik belirlenir: Etkiye göre P1-P4 seviyesi atanır.
3. Atama yapılır: Talep, ilgili sorumlu kişiye düşer ve ilk yanıt süresi başlar.
4. Çözüm uygulanır: Sorun giderilir, gerekirse geçici çözümle iş sürdürülür.
5. Onay alınır: Talep sahibi çözümü onaylar, talep kapanır ve kayıt saklanır.

Talep sahibine iyi bir bildirim akışı da gerekir: talep alındığında, öncelik belirlendiğinde ve çözüldüğünde bilgi verilmelidir. Aylık raporda açılan ve kapanan talep sayısı, ortalama yanıt ve çözüm süresi ve tekrarlayan sorunlar görülür.

Bakım Kapsamında Neler Yer Almaz?

Kapsam dışı kalanları baştan bilmek, sonradan "bu da dahildi sanıyorduk" tartışmasını önler. Tipik kapsam dışı işler şunlardır:

• Yeni özellik ve modüller: Yeni ekran, rapor ya da entegrasyon ayrı iş olarak fiyatlanır.
• Kullanıcı kaynaklı hatalar: Yanlış veri girişi ya da yetkisiz değişiklik sonucu oluşan sorunlar.
• Üçüncü taraf servis kesintileri: Ödeme, kargo ya da pazaryeri servisindeki arıza; yazılım tarafında yapılabilecekler yazılır, servisin kendisi kapsam dışıdır.
• Eğitim ve danışmanlık: Yeni kullanıcı eğitimleri ayrıca planlanır.
• Altyapı değişikliği: Sunucu taşıma ya da altyapı yenileme ayrı proje olabilir.

Yazılım Bakımı Neden İhmal Edilmemelidir?

Bakımsız yazılım güvenlik açığı ve uyumsuzluk biriktirir. Kullanılan bileşenlerin güvenlik güncellemeleri düzenli uygulanmazsa açıklar kapanmaz; pazaryeri ve ödeme servisleri API sürümlerini değiştirdiğinde güncellenmeyen entegrasyon bir sabah çalışmayı bırakır. Bakımı ertelemek maliyeti ortadan kaldırmaz, ileri bir tarihe ve genellikle daha pahalı bir müdahaleye taşır.

Bakımın bir parçası da yedekleme ve geri yükleme testidir; yedek alındığından emin olmak yetmez, geri dönülebildiği denenmelidir.

Okumanızı öneririz: Veri yedekleme nasıl yapılır? RPO, RTO ve 3-2-1 kuralı

Tekliflerdeki Bakım Kapsamı Nasıl Karşılaştırılır?

İki teklifteki bakım ücretini değil, ücretin neyi kapsadığını karşılaştırın: hangi bakım türleri dahil, destek saatleri ve kanallar neler, yanıt ve çözüm süreleri yazılı mı, çalışma süresi taahhüdü var mı, kaç saatlik iş içeriyor ve fazlası nasıl fiyatlanıyor? Yüzde aynı olsa bile kapsam iki kat farklı olabilir. Teklif karşılaştırmanın genel yöntemini yaptırma rehberimizde anlattık.

Bakım Sözleşmesi Ne Zaman Yeniden Değerlendirilmelidir?

Bakım sözleşmesi bir kez imzalanıp unutulan bir belge değildir; yazılım ve iş değiştikçe kapsamı da değişmelidir. Sözleşmeyi yılda en az bir kez, aşağıdaki durumlarda ise hemen gözden geçirin:

• Kullanıcı ve işlem sayısı belirgin arttığında: Yük büyüyünce destek saatleri ve çalışma süresi taahhüdü yetersiz kalabilir.
• Yazılım iş için daha kritik hâle geldiğinde: Yan araç olarak başlayan bir sistem sipariş akışının merkezine geldiyse öncelik süreleri sıkılaştırılmalıdır.
• Yeni entegrasyon eklendiğinde: Yeni bağlanan pazaryeri, kargo ya da ödeme servisi bakım kapsamına yazılmalıdır.
• Aynı tür talepler tekrar ettiğinde: Aylık raporda tekrarlayan sorunlar varsa çözüm, tek tek talepleri kapatmak değil kök nedeni gidermek olmalıdır.
• Destek süreleri tutmadığında: Hedef süreler sürekli aşılıyorsa ya kapsam ya da kaynak yeniden planlanmalıdır.

Yıllık gözden geçirmede aylık raporlardaki talep sayıları, ortalama yanıt ve çözüm süreleri ve kesinti kayıtları masaya getirilir; sözleşme bu verilere göre güncellenir.

Okumanızı öneririz: Destek talep yönetim sistemi nedir? Talep yaşam döngüsü, öncelik matrisi, SLA uyumu ve ekip kapasitesi rehberi

Okumanızı öneririz: Teknik Borç Nedir?

Okumanızı öneririz: Bulut mu Yerel Sunucu mu?

İnovabil ile Bakım ve Destek

İnovabil olarak yazılım canlıya alındıktan sonra da bakım, hata giderme, güncelleme ve yeni ihtiyaçlar için yanınızdayız; süreç adımlarımızın sonuncusu bakım ve destektir. Destek kapsamını projenin başında sizinle birlikte belirliyoruz ve yazılı hâle getiriyoruz; hangi işin bakım, hangisinin yeni geliştirme olduğunu örneklerle netleştiriyoruz.

Kendi ürünlerimiz Faprika, NetKasam ve Shopiyz'i her gün canlıda işlettiğimiz için yazılımı yalnızca teslim etmeyi değil, yıllarca ayakta tutmayı da biliyoruz. Mevcut ya da planlanan bir sistem için bakım kapsamını birlikte değerlendirmek isterseniz bize yazın.

Okumanızı öneririz: Yazılım geliştirme sürecimiz: analizden yayına adım adım

Sık Sorulan Sorular