Kurumsal bir yazılım projesi canlıya alındığında iş bitmez; asıl operasyon o gün başlar. Uygulama çalışıyor gibi görünse de güvenlik açıkları, performans daralmaları, entegrasyon hataları, mevzuat değişiklikleri ve kullanıcı talepleri zamanla birikir. Böyle bir tabloda yazılım bakım ve destek sözleşmesi, yalnızca “arıza olursa arayalım” mantığıyla ele alınmamalıdır. Aslında hizmet sürekliliğini, bütçe öngörülebilirliğini ve kurumsal hafızayı koruyan bir çerçevedir.
Özellikle ERP, CRM, B2B portal, mobil uygulama ve özel iş akışı yazılımlarında tek bir kesinti bile satış, operasyon ya da müşteri deneyimi üzerinde doğrudan etki yaratabilir. Örneğin sipariş akışını yöneten bir B2B platformda yaşanan 2 saatlik erişim problemi, teknik açıdan kısa görünebilir; ancak mesai saatleri içinde olursa teklif süreçleri, stok teyidi ve bayi siparişleri aynı anda durabilir. İyi kurgulanmış bir bakım sözleşmesi, bu gibi anlarda kimin ne kadar sürede müdahale edeceğini ve hangi kapsamda sorumluluk alacağını en baştan netleştirir.
Bakım ve destek sözleşmesi tam olarak neyi güvence altına alır?
Birçok kurum bakım ile geliştirmeyi, destek ile danışmanlığı aynı şey sanabiliyor. Oysa sözleşmenin kapsamı net değilse beklenti uyuşmazlığı başlar. Pratikte bu sözleşmeler genelde 4 ana alanı tanımlar: hata giderme, izleme ve önleyici bakım, küçük iyileştirmeler, olay bazlı teknik destek. Kurum açısından kritik olan, bu başlıkların saat, öncelik seviyesi ve yanıt süresiyle birlikte yazılmasıdır.
Somut bir örnek verelim. Kritik seviye bir hatada ilk geri dönüş süresi 30 dakika, geçici çözüm hedefi 4 saat, kalıcı çözüm hedefi 1 iş günü olarak tanımlanabilir. Daha düşük öncelikli kullanıcı arayüzü hatalarında ise bu süreler farklı tutulur. Böylece hem yazılım firması hem de kurum aynı hizmet seviyesine göre hareket eder.
Sözleşmede açıkça yazılması gereken maddeler
- Destek kanalının tanımı: e-posta, ticket sistemi, telefon, acil durum hattı
- Çalışma saatleri: 5x8, 7x24 ya da kritik sistemler için nöbet kapsamı
- Olay öncelik seviyeleri: kritik, yüksek, orta, düşük
- SLA metrikleri: ilk yanıt, müdahale, geçici çözüm, kalıcı çözüm süreleri
- Versiyon güncelleme ve güvenlik yama kapsamı
- Yedekleme, geri dönüş testi ve log saklama sorumlulukları
- Üçüncü taraf servislerde sınırlar: ödeme altyapısı, kargo API’si, e-fatura entegrasyonu gibi
Bu maddeler yazılmadığında mesele teknik olmaktan çıkar, yönetsel hale gelir. “Destek veriyoruz” ifadesi tek başına yeterli değildir; hangi olayda kaç saat içinde aksiyon alınacağı mutlaka belirlenmelidir.
Kesinti süresi küçüktür sanılır, etkisi büyük olabilir
Kurumsal yazılımlarda her hata aynı etkiye sahip değildir. İnsan kaynakları portalındaki bir rapor filtresi arızası ile sipariş kabul ekranının çalışmaması aynı klasmanda değerlendirilemez. Bakım ve destek sözleşmesinin kritik rolü, bu ayrımı operasyonel bir modele dönüştürmesidir.
Mesela günde 1.200 sipariş geçen bir platform düşünelim. Siparişlerin %40’ı saat 10:00–14:00 arasında oluşuyorsa, bu dilimde yaşanan 45 dakikalık bir entegrasyon kopması yalnızca “45 dakika kesinti” anlamına gelmez. Bu sırada kuyrukta kalan işlemler, mükerrer denemeler, çağrı merkezi yükü ve müşteri memnuniyetsizliği devreye girer. Bazı sektörlerde sorun mesai sonrasında fark edilir ve etkisi ertesi gün katlanır.
İyi bir sözleşme yalnızca arızayı çözmeyi değil, arızanın etkisini azaltmayı da hedefler. Geçici çözüm prosedürü, rollback planı, kuyruk mekanizması ve manuel operasyon adımları önceden tanımlandığında kriz çok daha kontrollü yönetilir.
Gerçek hayatta sık görülen aksama senaryoları
- API sağlayıcısı format değiştirir, sipariş aktarımı durur
- Mobil uygulama yeni işletim sistemi sürümünde çökme oranı yükselir
- Veritabanı indeksleri bozulur, rapor ekranları 3 saniyeden 40 saniyeye çıkar
- SSL sertifikası yenilenmez, kullanıcılar giriş ekranında hata alır
Bunların her biri farklı uzmanlık gerektirir. Sözleşme olmadığında ekipler çoğu zaman doğru kişiye geç ulaşır. Süre uzar, maliyet artar.
Güvenlik ve uyumluluk tarafında sözleşme neden zorunlu hale gelir?
Yazılım sistemleri canlıya çıktıktan sonra tehdit yüzeyi sabit kalmaz. Yeni kütüphane sürümleri çıkar, bilinen zafiyetler duyurulur, işletim sistemi paketleri güncellenir. Açık kaynak bileşen kullanan modern projelerde onlarca bağımlılık bulunabilir. Sadece bu gerçek bile düzenli bakım ihtiyacını açıkça ortaya koyar.
Özellikle kişisel veri işleyen CRM, müşteri portalı, çağrı merkezi uygulaması ya da saha operasyon sistemlerinde güvenlik yamalarının bir takvime bağlanması gerekir. Örneğin aylık güvenlik taraması, üç ayda bir erişim yetkisi gözden geçirme ve yılda en az 1 kez felaket kurtarma senaryosu testi sözleşmede yer alabilir. Bu maddeler, kurumun iç denetim süreçlerinde de ciddi kolaylık sağlar.
Uyumluluk boyutu da benzer ölçüde önemlidir. E-fatura, e-irsaliye, ödeme sistemleri, KVKK kapsamındaki veri işleme süreçleri veya sektörel regülasyonlar değişebilir. Geliştirilen yazılımın bu değişikliklere uyum sağlaması bazen küçük bir konfigürasyon, bazen de planlı bir revizyon gerektirir. Sözleşme bu alanı tanımlamazsa her değişiklik acil proje gibi ele alınır.
Asgari güvenlik bakım kalemleri
- Bağımlılık ve paket güncellemeleri
- Yetki matrisinin periyodik kontrolü
- Log izleme ve anomali takibi
- Yedekleme başarısının doğrulanması
- Sertifika ve domain süre takibi
Buradaki kritik nokta şu: güvenlik yalnızca saldırı olduktan sonra konuşulacak bir başlık değildir. Bakım sözleşmesi, önleyici yaklaşımı kurumsal bir düzene dönüştürür.
Maliyet kontrolü açısından bakım sözleşmesi nasıl avantaj sağlar?
Bakım sözleşmesi olmayan kurumlarda teknik destek çoğunlukla olay bazlı satın alınır. İlk bakışta esnek görünebilir; ancak birkaç ay içinde bütçe öngörüsü bozulur. Acil müdahaleler, mesai dışı çalışmalar, dokümantasyonsuz kod incelemeleri ve tekrar eden problemler toplam maliyeti yükseltir. Üstelik kurum içi ekipler arızayı tarif etmek, önceliklendirmek ve geçmiş değişiklikleri anlatmak için ekstra zaman harcar.
Sözleşmeli modelde aylık ya da çeyreklik kapasite planlanabilir. Örneğin her ay 20 saat bakım kapasitesi, buna ek olarak kritik olaylar için ayrı SLA ve sürüm güncellemeleri için sabit pencere tanımlanabilir. Bu yapı, finans ekiplerine daha öngörülebilir bir bütçe sunar. Operasyon ekipleri de “bu ay sorun çıkarsa ne olacak?” sorusunu sürekli yeniden sormak zorunda kalmaz.
Bir diğer görünmeyen maliyet kalemi bilgi kaybıdır. Yazılımı geliştiren ekip değiştiğinde, sistemin neden o şekilde tasarlandığını anlamak zaman alır. Aktif bakım sözleşmesi, dokümantasyon güncelliğini ve devir bilgisini daha canlı tutar. Bu bile tek başına haftalar kazandırabilir.
Reaktif model ile planlı model arasındaki fark
Reaktif yaklaşımda kurum, sorun çıktığında destek arar. Planlı modelde ise loglar izlenir, performans trendleri okunur, küçük problemler büyümeden ele alınır. Mesela CPU kullanımı son 6 hafta boyunca kademeli olarak yükseliyorsa, bu veri kapasite artışı ya da sorgu optimizasyonu ihtiyacını erken gösterir. Aksi halde bir sabah uygulama yavaşladığında herkes aynı anda alarma geçer.
Kurumsal hafıza, süreç sürekliliği ve tedarikçi yönetimi
Özel yazılımlar genellikle birden fazla bileşenin birleşiminden oluşur: web uygulaması, mobil istemci, veritabanı, API katmanı, üçüncü taraf servisler, bulut altyapısı. Zaman içinde ekiplerde değişim olur. Projeyi başlatan ürün yöneticisi ayrılabilir, iç IT ekibi yeniden yapılandırılabilir, dış tedarikçiler değişebilir. Tam da bu noktada bakım ve destek sözleşmesi, teknik olduğu kadar yönetsel bir araç haline gelir.
İyi hazırlanmış bir çerçevede yalnızca destek süreleri değil, bilgi devri ve kayıt disiplini de tanımlanır. Ticket geçmişi, değişiklik kayıtları, sürüm notları, erişim envanteri ve mimari dokümanlar düzenli tutulduğunda kurum tek kişiye bağımlı hale gelmez. Özellikle 2 yıldan uzun süredir kullanılan sistemlerde bu fark çok net hissedilir.
Sağlıklı bir operasyon için istenebilecek teslimatlar
- Aylık olay ve çözüm raporu
- Versiyon değişiklik listesi
- Erişim ve yetki envanteri güncellemesi
- Yedekleme ve geri yükleme test kaydı
- Teknik borç ve öneri listesi
Bu çıktıların her biri yönetime görünürlük sağlar. Kurum, yazılımın yalnızca “çalışıp çalışmadığını” değil, hangi risklerle işletildiğini de görür.
Sözleşme hazırlanırken hangi teknik sorular sorulmalı?
Her bakım sözleşmesi kuruma özel olmalıdır. 7x24 çalışan bir saha servis platformu ile yalnızca ofis saatlerinde kullanılan intranet uygulamasının aynı SLA yapısına ihtiyacı yoktur. Bu nedenle satın alma aşamasında birkaç temel sorunun yanıtı aranmalıdır.
- Sistem için kabul edilebilir maksimum kesinti süresi kaç saat?
- Hangi modüller gelir üretimini ya da operasyonu doğrudan etkiliyor?
- Yedekten geri dönüş hedefi nedir; örneğin RTO 2 saat, RPO 15 dakika mı?
- Bulut altyapısı, veritabanı ve uygulama katmanında sorumluluk kimde?
- Küçük geliştirme talepleri bakım kapsamına giriyor mu?
- Mesai dışı kritik olaylarda kim onay verecek?
Burada teknik çerçeve kadar iletişim modeli de belirleyicidir. Kurum tarafında ürün sahibi, IT sorumlusu ve iş birimi temsilcisi net değilse en iyi sözleşme bile sahada yavaş işler.
Sonuç: Yazılımın değeri, sürdürülebilir işletimle korunur
Kurumsal firmalar için yazılım yatırımı yalnızca geliştirme bütçesinden ibaret değildir. Asıl değer, sistemin aylar ve yıllar boyunca güvenli, hızlı ve uyumlu biçimde çalışmasında ortaya çıkar. Yazılım bakım ve destek sözleşmesi bu sürekliliğin sigortası gibi düşünülmelidir; ancak pasif bir evrak olarak değil, ölçülebilir hizmet seviyeleri içeren operasyonel bir mekanizma olarak.
Canlıdaki yazılımı sahipsiz bırakmak, çoğu zaman ilk anda fark edilmeyen ama biriktikçe pahalıya mal olan riskler üretir. Düzenli bakım, net SLA, kayıtlı süreçler ve doğru teknik sahiplik modeli kurulduğunda kurum hem kesinti riskini hem de belirsiz maliyetleri daha iyi yönetir. Özel yazılımın gerçek kurumsal değeri de tam bu noktada korunur.
