Yazılım bakım sözleşmesi, canlıya alınmış bir yazılımın hatalarının giderilmesini, güvenlik ve uyumluluk güncellemelerini, küçük geliştirmeleri ve kullanıcı desteğini belirli süreler ve kurallarla yükleniciye bağlayan anlaşmadır. İyi bir sözleşme "destek veririz" demekle yetinmez; neyin dahil olduğunu, arızanın kaç saatte ele alınacağını, kimin neyi kanıtlayacağını ve ayrılık halinde neyin teslim edileceğini yazar.
Kısaca
- Bakım sözleşmesi geliştirme sözleşmesinin devamıdır; yazılım teslim edildiği gün eskimeye başlar.
- Kapsam dört bakım türüyle tanımlanmalıdır: düzeltici, uyarlayıcı, iyileştirici ve önleyici.
- Yanıt süresi ile çözüm süresi ayrı yazılmalı, öncelik seviyeleri somut örneklerle tanımlanmalıdır.
- Verizon DBIR 2026'ya göre zafiyet istismarı, ihlallerde en yaygın ilk erişim yolu oldu; güvenlik yaması bakımın dışında bırakılamaz.
- Sözleşme bitince kaynak kodu, erişimler ve belgelerin nasıl devredileceği baştan yazılmalıdır.
Bakım sözleşmesi olmadan ne kaybedersiniz?
Özel yazılım teslim edildiği an sabit kalmaz. İşletim sistemi, veritabanı, tarayıcılar, e-fatura gibi entegre olduğu dış servisler ve mevzuat değişir; kullanıcılar da ilk aylarda testte görülmeyen hataları bulur. Bakım sözleşmesi yoksa her arıza yeni bir pazarlıkla başlar ve en acil anda fiyat da öncelik de yüklenicinin elindedir.
Bu bağımlılık KOBİ'lerde daha keskindir. TÜİK'in 2026 Girişimlerde Bilişim Teknolojileri Kullanım Araştırması'na göre girişimlerin yalnızca %15,2'si BİT uzmanı istihdam ediyor; 10-49 çalışanlı firmalarda bu oran %10,8. Yani çoğu firmada yazılımı içeriden onaracak biri yoktur ve yazılı bir bakım sözleşmesi en önemli güvence olur.
Güvenlik tarafında maliyet daha da görünürdür. Verizon 2026 Veri İhlali Araştırmaları Raporu'na göre zafiyet istismarı %31 ile ihlallerde en yaygın ilk erişim yolu oldu. Kullandığınız kütüphaneler ve çerçeveler için yayımlanan yamaları kimin, ne kadar sürede uygulayacağı yazılı değilse, açık bir kapı bırakmış olursunuz. Bu sürecin kurum içi tarafını yama yönetimi süreci yazısında anlattık.
Yazılım bakım sözleşmesi neyi kapsamalı?
Kapsam tartışmalarının çoğu "bu hata mı, yeni istek mi?" sorusundan çıkar. Bunu önlemenin en temiz yolu, yazılım bakımını ISO/IEC 14764 standardındaki dört türe ayırıp her birinin sözleşmede nasıl ele alınacağını yazmaktır.
| Bakım türü | Ne demek? | Örnek | Sözleşmede tipik karşılığı |
|---|---|---|---|
| Düzeltici | Teslim edilen işlevin hatalı çalışmasını gidermek | Fatura toplamı yanlış hesaplanıyor | Bakım bedeline dahil, öncelik ve sürelere bağlı |
| Uyarlayıcı | Değişen ortama uyum sağlamak | Entegre servis API sürümünü değiştirdi, mevzuat formatı güncellendi | Genellikle dahil; büyük değişiklikler için üst sınır |
| İyileştirici | Performans ve kullanım kolaylığı geliştirmek, küçük yeni istekler | Rapora iki yeni sütun, ekran hızlandırma | Aylık saat havuzundan düşülür |
| Önleyici | Sorun çıkmadan riski azaltmak | Kütüphane ve güvenlik güncellemeleri, log ve disk kontrolü | Takvimli; raporla kanıtlanır |
Yeni modül, yeni entegrasyon ya da iş akışını değiştiren büyük istekler bakım değil, geliştirmedir. Bunlar ayrı tekliflendirilmeli ve teknik şartname mantığıyla tanımlanmalıdır. Bakım ile geliştirme arasındaki çizgiyi bir tabloyla sözleşmeye eklemek, yıllık tartışmaların büyük kısmını bitirir.
Kapsamın bir de "nerede" boyutu vardır. Yazılım sizin sunucunuzda çalışıyorsa sunucu, işletim sistemi ve yedek kimin sorumluluğunda, bunu ayrıca yazın. SaaS mı kurulu yazılım mı kararınız bu sorumluluk dağılımını doğrudan belirler.
SLA nasıl yazılır? Yanıt süresi ile çözüm süresi aynı şey değildir
Hizmet seviyesi anlaşması (SLA), bakım sözleşmesinin ölçülebilir kalbidir. En sık yapılan hata tek bir "4 saat içinde müdahale" cümlesi yazmaktır: Bu, telefonun açılacağını söyler, sorunun çözüleceğini değil. Sağlıklı bir SLA en az üç süreyi ayırır: ilk yanıt, geçici çözüm ve kalıcı çözüm.
Öncelik seviyeleri de soyut kalmamalıdır. "Kritik" kelimesinin anlamı sözleşmede örnekle yazılmazsa, her taraf kendi işine geleni anlar. Aşağıdaki çerçeve bir başlangıç noktasıdır; süreleri yazılımın işinize ne kadar kritik olduğuna göre birlikte belirleyin.
| Öncelik | Tanım ve örnek | Ne ölçülür? |
|---|---|---|
| P1 Kritik | Sistem tamamen kullanılamıyor ya da veri kaybı riski var; sipariş alınamıyor | İlk yanıt, geçici çözüm, kalıcı çözüm; mesai dışı dahil |
| P2 Yüksek | Ana işlevlerden biri çalışmıyor, geçici bir yol var | İlk yanıt ve çözüm süresi, mesai içi |
| P3 Normal | Tek ekranda hata, iş akışı aksamıyor | Çözümün hangi planlı sürümde yayımlanacağı |
| P4 Talep | Soru, eğitim, küçük düzenleme | Saat havuzundan, planlı |
Sürelerin yanında ölçüm yöntemini de yazın: talep hangi kanaldan açılır, saat ne zaman başlar ve ne zaman durur, aylık raporda hangi rakamlar yer alır? Ortalama onarım süresi gibi göstergeleri MTTR ve MTBF tanımlarıyla izlemek, tartışmayı izlenim yerine veriye taşır. SLA ihlalinde ne olacağı da açık olmalıdır: bedel indirimi, ek saat ya da tekrar eden ihlalde fesih hakkı.
İmzalamadan önce kontrol edilecek 10 madde
Sözleşme taslağını okurken aşağıdaki listeyi yanınıza alın. Bir madde yoksa ya da belirsizse, imzadan önce yazılı olarak netleştirin.
- Kapsam tablosu: Dört bakım türünden hangilerinin dahil olduğu ve geliştirmeyle sınırı.
- Öncelik tanımları ve süreler: Her seviye için örnek, ilk yanıt ve çözüm süresi.
- Destek kanalı ve saatleri: Talep sistemi, telefon, mesai dışı ulaşım ve kimin arayabileceği.
- Saat havuzu: Aylık iyileştirme saatinin miktarı, devri ve aşımın nasıl fiyatlandığı.
- Güvenlik güncellemeleri: Kritik yamaların hangi sürede uygulanacağı ve raporlanması.
- Yedek ve geri dönüş: Yedeğin kimde olduğu, sıklığı ve geri yükleme testinin yapılıp yapılmadığı.
- Sürüm ve test süreci: Değişikliklerin önce test ortamında denenmesi, kabul ve geri alma planı.
- Raporlama: Aylık talep, çözüm süresi ve yapılan önleyici işlerin listesi.
- Kaynak kodu ve erişimler: Güncel kodun nerede tutulduğu, sunucu ve hesapların kimin adına olduğu.
- Süre, fesih ve devir: Yenileme koşulları, fiyat güncelleme yöntemi ve ayrılıkta devir yükümlülüğü.
Altıncı madde çoğu zaman kâğıt üzerinde kalır; yedeğin gerçekten geri dönüp dönmediğini yedekleme ve geri yükleme testi rehberindeki adımlarla doğrulayın. Dokuzuncu madde ise ayrı bir yazıyı hak edecek kadar önemlidir; ayrıntısını yazılım sözleşmesi ve kaynak kodu yazısında bulabilirsiniz.
Bakım bedeli nasıl belirlenir?
Piyasada üç model yaygındır: sabit aylık ücret, kullanılan saat kadar ödeme ve ikisinin karışımı. Sabit ücret bütçeyi öngörülebilir kılar ama kapsamı belirsizse yüklenici "dahil değil" demeye başlar. Saatlik model esnektir ama acil bir arızada hem süreyi hem bedeli tahmin etmek zorlaşır.
Çoğu işletme için en dengeli yapı, sabit bir taban ücretle düzeltici ve önleyici bakımı güvenceye almak, iyileştirmeleri de aylık saat havuzuyla yönetmektir. Bedelin neye göre belirlendiğini, toplam sahip olma maliyetiyle birlikte yazılım projesi maliyeti yazısında ele aldık. Yıllık bakım bedelini tek başına değil, yazılımın aksadığı bir günün işinize maliyetiyle karşılaştırarak değerlendirin.
Bakım sözleşmesinde sık yapılan hatalar
İlk hata, sözleşmeyi geliştirme bitince düşünmektir. Bakım koşulları teklif aşamasında konuşulmazsa pazarlık gücü teslimden sonra tümüyle yükleniciye geçer. Yazılım firmalarını karşılaştırırken bakım tekliflerini de istemek, yazılım firması seçerken bakılacak ölçütlerin parçası olmalıdır.
İkinci hata, ölçmeden izlemektir. Aylık rapor istenmezse SLA'nın tutulup tutulmadığını kimse bilmez. Ara teslimlerde uyguladığınız disiplini bakım döneminde de sürdürmek için yazılım projesinde yüklenici denetimi çerçevesini kullanabilirsiniz.
Üçüncü hata, eskiyen altyapıyı bakımla sürdürmeye çalışmaktır. Desteği biten bir dil sürümü ya da çerçeve üzerinde çalışan yazılım, her ay daha pahalı yamalanır. Bir noktada bakım bütçesini eski yazılım modernizasyonu planına yönlendirmek daha akılcıdır. NIST SP 800-40 Rev. 4 de yamalamayı önleyici bakımın kritik bir bileşeni ve işin olağan maliyeti olarak tanımlar; yani güncelleme bütçesi isteğe bağlı bir kalem değildir.
Digital Bridge bakım ve desteği nasıl yürütür?
Digital Bridge 2013'ten beri Adana'dan yazılım ve donanım projelerini aynı ekipte yürütüyor. Özel web yazılımı projelerimiz yerinde keşif ve ihtiyaç analiziyle başlar, kapsamı ve bedeli yazan teklifle ilerler; canlıya geçtikten sonra da muhatabınız sistemi yazan ekiptir.
- Teknik destek 7/24: Kullanıcılar sistemi kullanmaya başladıktan sonra destek kesintisiz sürer.
- Yeni ihtiyaçlar ayrı modül olarak: Sonradan gelen istekler mevcut modülleri bozmadan eklenir.
- Kaynak kodu sizde: Proje tesliminde kaynak kodu, veritabanı şeması ve teknik belgeler size teslim edilir; bu sayede desteği bizden almak zorunda değilsiniz ve ilişki bağımlılık değil, hizmet kalitesi üzerine kurulur.
ERP, CRM, depo ve entegrasyon projelerinin tamamını yazılım çözümleri sayfasında, ekibimizi ve çalışma biçimimizi kurumsal sayfasında bulabilirsiniz. Yazılım konusundaki diğer rehberler için yazılım blog kategorisine göz atın.
Sonraki adım
Bugün kullandığınız yazılım için üç soruyu yanıtlayın: Kritik bir arızada kimi, hangi kanaldan arayacaksınız? Son güvenlik güncellemesi ne zaman yapıldı? Yükleniciyle yollar ayrılsa kod ve erişimler sizde mi? Bir yanıt bile belirsizse iletişim sayfamızdan ya da 0850 346 41 09 numarasından bize ulaşın; yazılımınızın bakım ve destek ihtiyacını birlikte konuşalım ya da yeni projenizi canlıya geçiş sonrasını da düşünerek baştan doğru planlayalım.