Yazılım Bakım ve Destek Anlaşması: Neleri Kapsamalı, Ne Kadar Olmalı?

Yazılım bakım anlaşması, teslim edilen bir sistemin sonraki yıllarda çalışır, güvenli ve güncel kalmasını güvence altına alan sözleşmedir. Şirketler geliştirme bedelini uzun uzun pazarlık eder, bakım maddesini ise çoğu zaman son sayfada tek satırla geçer. Oysa yazılımın ömrü boyunca ödenen bakım ve destek tutarı, ilk geliştirme bedelini geçebilir ve yazılımla ilgili yaşanan sorunların çoğu teslimden sonra başlar.

Bu yazıda yazılım bakım anlaşmasının ne olduğunu, bakım ile desteğin nasıl ayrıldığını, anlaşmanın neleri kapsaması gerektiğini, yanıt ve çözüm sürelerinin nasıl belirlendiğini, bedelin neye göre şekillendiğini, barındırmanın kimin sorumluluğunda olduğunu ve kaçınılması gereken maddeleri anlatacağız. Teslime yaklaşan bir projeniz varsa bu başlıklar imza atmadan önce netleşmelidir.

Yazılım bakım anlaşması nedir?

Yazılım bakım anlaşması, tedarikçinin teslim ettiği yazılımı belirli bir süre boyunca hatasız, güvenli ve çalışır tutmayı, teknoloji güncellemelerini yapmayı ve kullanıcılara belirlenen kapsamda destek vermeyi taahhüt ettiği, karşılığında düzenli bir bedel aldığı sözleşmedir. Garanti süresi bittikten sonra devreye girer ve genellikle yıllık yenilenir.

Bakımı gerektiren şey yazılımın bozulması değil, çevresinin değişmesidir. İşletim sistemi güncellenir, tarayıcılar değişir, kullanılan kütüphanelerde güvenlik açığı bulunur, muhasebe programı yeni sürüme geçer, e-fatura sağlayıcısı arayüzünü değiştirir. Hiçbiri yazılımınızın hatası değildir ama her biri yazılımınızı etkiler. Bakım, bu değişimlere ayak uydurmanın adıdır.

Bakım anlaşması olmayan bir yazılım, ilk yıl sorunsuz çalışır, ikinci yıl küçük uyumsuzluklar başlar, üçüncü yıl güvenlik güncellemesi almayan bir sistem olarak risk haline gelir. Bu süreç sessizdir ve genellikle ciddi bir sorun çıkana kadar fark edilmez.

Bakım ile destek arasındaki fark ne?

Bakım, yazılımın kendisine yöneliktir: hata düzeltme, güvenlik güncellemeleri, kütüphane ve altyapı yükseltmeleri, performans iyileştirmeleri. Destek ise kullanıcıya yöneliktir: soru cevaplama, kullanım yardımı, yetki tanımlama, rapor alma desteği. İkisi çoğu zaman tek anlaşmada birleşir ama ayrı fiyatlanması ve ayrı ölçülmesi daha sağlıklıdır.

Ayrımın pratik önemi şudur: destek yükü, kullanıcı sayısı ve eğitim düzeyiyle artar; bakım yükü ise sistemin büyüklüğü ve entegrasyon sayısıyla artar. Yüz kullanıcılı ama basit bir sistemde destek ağır, bakım hafiftir; on kullanıcılı ama beş entegrasyonlu bir sistemde ise tersi geçerlidir. İkisini tek kalemde toplamak, birinin diğerini sübvanse etmesine yol açar.

Bir üçüncü kategori de geliştirmedir: yeni ekran, yeni rapor, yeni iş kuralı. Bu, ne bakım ne destektir ve bakım anlaşmasının içinde sınırsız biçimde yer almamalıdır. Sağlıklı anlaşmalar, aylık belirli bir saat kadar küçük geliştirmeyi kapsar, ötesini ayrıca fiyatlar.

Bakım anlaşması neleri kapsamalı?

İyi bir bakım anlaşması şunları kapsamalıdır: hata düzeltme, güvenlik yamaları ve kütüphane güncellemeleri, altyapı ve sunucu izleme, düzenli yedekleme ve yedekten dönüş testi, entegrasyon uyumluluğu (muhasebe, e-fatura, SMS), belirli saat kadar kullanıcı desteği, küçük geliştirmeler için aylık kota ve dönemsel sağlık raporu.

Yedekleme maddesi özellikle net olmalıdır: ne sıklıkla yedek alınıyor, nerede saklanıyor, kaç gün geriye gidilebiliyor ve yedekten dönüş hiç denenmiş mi? Alınan ama hiç test edilmemiş yedek, güvence değil varsayımdır. Anlaşmada yılda en az bir kez yedekten dönüş provası yapılacağı yazılmalıdır.

İzleme maddesi de önemlidir. Sistemin çöktüğünü kullanıcıdan önce tedarikçinin fark etmesi, bakımın kalitesini belirler. Sunucu kaynak kullanımı, hata kayıtları ve yanıt süreleri izleniyor ve eşik aşıldığında tedarikçiye uyarı gidiyorsa, çoğu sorun kullanıcıya yansımadan çözülür.

SLA nedir, yanıt ve çözüm süreleri nasıl belirlenir?

SLA (hizmet seviyesi anlaşması), bir sorun bildirildiğinde tedarikçinin ne kadar sürede yanıt vereceğini ve ne kadar sürede çözeceğini, sorunun önem derecesine göre tanımlayan bölümdür. Sistemi tümüyle durduran bir sorun için saatler, kozmetik bir hata için günler ölçeğinde süreler belirlenir.

Önem dereceleri genellikle üç ya da dört seviyede tanımlanır: kritik (sistem çalışmıyor ya da veri kaybı riski var), yüksek (ana bir işlev çalışmıyor ama geçici çözüm var), orta (ikincil bir işlev etkileniyor) ve düşük (görsel ya da küçük bir kullanım sorunu). Her seviye için ayrı yanıt süresi ve ayrı hedef çözüm süresi yazılmalıdır. Yanıt süresi 'ilgilenmeye başlama' süresidir, çözüm süresiyle karıştırılmamalıdır.

Destek saatleri de SLA'nın parçasıdır. Mesai saatleri içinde mi, hafta sonu dahil mi, gece kritik sorunlarda ulaşılabilecek bir hat var mı? Yedi gün yirmi dört saat destek her işletme için gerekli değildir ve maliyeti belirgin biçimde artırır; işinizin gerçekten hangi saatlerde durmaması gerektiğine göre karar verin.

Yazılım bakım anlaşması ne kadar olmalı?

Bakım bedeli için sektörde yaygın yaklaşım, yıllık bakımı proje geliştirme bedelinin belirli bir yüzdesi olarak belirlemektir; bu oran kapsamın genişliğine, SLA sıkılığına, entegrasyon sayısına ve destek saatlerine göre değişir. Kesin bir rakam yerine, bedelin hangi kalemlerden oluştuğunu görmek daha yol göstericidir.

Bedeli yukarı çeken faktörler şunlardır: kısa çözüm süreleri, mesai dışı destek, çok sayıda entegrasyon, yüksek kullanıcı sayısı ve aylık geliştirme kotasının genişliği. Aşağı çeken faktörler ise net bir kapsam, kendi kendini izleyen bir altyapı, eğitimli kullanıcılar ve belgelenmiş bir sistemdir. Bakımı ucuzlatmanın en iyi yolu, geliştirme aşamasında iyi belgeleme ve otomatik testtir.

Aylık sabit bedel ile kullanıldıkça ödeme modeli arasında da seçim yapılır. Sabit bedel öngörülebilir ama sorunsuz aylarda da ödenir; kullanıldıkça ödeme ise sorun çıkmayan aylarda ucuzdur ama tedarikçinin sizi öncelik listesinde tutması için bir gerekçesi kalmaz. Karma model, düşük bir sabit bedel artı saat başı ek iş, çoğu KOBİ için dengeli bir çözümdür.

Barındırma ve altyapı kimin sorumluluğunda?

Barındırma, yani yazılımın çalıştığı sunucu ve bulut altyapısı, bakım anlaşmasından ayrı bir kalemdir ve kimin adına açıldığı, kimin ödediği ve kimin yönettiği açıkça yazılmalıdır. En sağlıklı düzen, bulut hesabının müşteri adına açılıp yönetiminin tedarikçiye verilmesidir; böylece ayrılık durumunda altyapı sizde kalır.

Azure, AWS ya da Vercel gibi altyapılarda maliyet kullanıma göre değişir ve bakım bedelinden bağımsız olarak faturalanır. Tedarikçi bu maliyeti kendi faturasına ekleyerek yansıtabilir, ancak hesabın kimin adına olduğu değişmez bir madde olmalıdır. Tedarikçi adına açılmış bir bulut hesabı, ayrılık anında yazılımınızın nerede ve nasıl taşınacağı sorusunu doğurur.

Alan adı, SSL sertifikası, e-posta ve SMS servisi gibi bağımlı hesaplar da aynı mantıkla müşteri adına olmalıdır. Bu hesapların listesi, erişim bilgileri ve yenileme tarihleri bakım anlaşmasının ekinde tutulmalı, tedarikçi her yenilemeyi bildirmelidir.

Anlaşmada kaçınılması gereken maddeler neler?

Kaçınılması gereken maddeler şunlardır: bakım ödemesi kesildiğinde yazılımın kullanım hakkının sona ermesi, kapsamı belirsiz 'tüm destek dahil' ifadeleri, SLA'sız taahhütler, yedeklemenin müşteri sorumluluğunda bırakılması, otomatik yenilenen ve tek taraflı zamlanan bedeller, çıkışta veri ve kod tesliminin düzenlenmemiş olması.

İlk madde en tehlikelisidir. Bakım anlaşması bittiğinde yazılım çalışmaya devam etmeli, yalnızca güncelleme ve destek kesilmelidir. Bakım ile kullanım hakkının birbirine bağlanması, yazılımı fiilen kiraya dönüştürür. 'Tüm destek dahil' ifadesi ise kulağa cömert gelir ama sınır yoksa tedarikçi bir noktada kısıtlamaya gider ve tartışma başlar; net bir saat kotası iki taraf için de daha adildir.

Sonlandırma koşulları da okunmalıdır. Anlaşmanın hangi sürede, hangi bildirimle sona erdirilebileceği, sona erme anında tedarikçinin kodu, veriyi, belgeleri ve hesap erişimlerini ne kadar sürede devredeceği yazılı olmalıdır. Bu madde yoksa şirket değiştirmek kağıt üstünde mümkün, pratikte imkansız olur.

Rezon ile bakım nasıl işler?

Rezon, şirketlere özel CRM, ERP ve bayi portalı sistemleri kuran, kendi SaaS ürünlerini canlıda işleten İstanbul merkezli bir yazılım çözümleri şirketidir. FizyoDesk, OdyoDesk ve Planzio'yu her gün canlıda işlettiğimiz için izleme, yedekleme, güvenlik güncellemesi ve destek bizim için proje sonrası bir ek iş değil, günlük rutindir; özel projelerde de aynı disiplini uygularız.

Bakım anlaşmalarımızda kapsam, SLA seviyeleri ve aylık geliştirme kotası ayrı ayrı yazılır; bulut ve servis hesapları müşteri adına açılır, bakım bitse de yazılım çalışmaya devam eder çünkü kaynak kod müşteriye aittir. Çözümler sayfamızdaki özel yazılım bölümünde yaklaşımımızı görebilir, mevcut bir sisteminizin bakımını devralmamızı isterseniz iletişim sayfamızdan yazabilirsiniz; ilk değerlendirme görüşmesi ücretsizdir.