Pazartesi sabahı saat 06:40. Vardiya başlamış, kalite kontrolcü giriş muayenesi kaydını açamıyor, hat başındaki tabletlerde iş talimatı gelmiyor. Yazılım tedarikçisinin destek hattı 09:00'da açılıyor. Satınalma müdürü sözleşmeyi çıkarıyor ve destek maddesini okuyor: "Tedarikçi, bildirilen arızalara makul süre içinde müdahale eder." O sabah dört saat kaybettik ve kaybın hiçbir hukuki karşılığı yoktu. Yazılım bakım destek sözleşmesi imzalarken yapılan hataların bedeli işte tam olarak böyle, en kötü sabahta ödeniyor.
Bakım sözleşmesi aslında neyi satın alıyor
Bakım ve destek sözleşmesi tek bir hizmet değil, birbirinden farklı dört şeyin paketidir: hata giderme, sürüm yükseltme hakkı, kullanım desteği ve öngörülemeyen durumlarda erişim garantisi. Bu dördü ayrı ayrı fiyatlanabilir ve ayrı ayrı sınırlanabilir. Sözleşmeyi okurken önce bu dördünü kalemlere ayırıp her birinin karşısına ne aldığınızı yazın. Çoğu firma bu ayrımı yapmadan imzalar ve yıl sonunda ödediği bedelin hangi hizmeti kapsadığını bilmez. Yazılım bakım destek sözleşmesi okunurken yapılacak ilk iş bu ayrımdır.
Aşağıdaki altı madde, sahada en çok soruna yol açan başlıklar. Sözleşmeyi hukukla birlikte okurken bu altı maddenin her birinde net bir cümle görene kadar imza atmayın. Kalite tarafında zaten alışık olduğumuz bir mantık var: taahhüt ölçülebilir değilse taahhüt değildir.
1. Yıllık bakım bedeli ve artış formülü
Kurumsal yazılımda yıllık bakım bedeli, lisans bedelinin belirli bir yüzdesi olarak hesaplanır. Ama asıl mesele oranın kendisi değil. Sorulacak üç soru şu: bu oran hangi tutar üzerinden hesaplanıyor, oran her yıl aynı mı kalıyor, ve tutar hangi endekse bağlı olarak artıyor? Kullanıcı sayısı arttıkça lisans tabanı büyür ve sabit görünen yüzde oranı, mutlak tutarda beklediğinizin çok üstüne çıkar.
Sözleşmeye koydurulacak en değerli cümle bir üst sınırdır: yıllık bakım bedeli artışı, bir önceki yıl bedelinin belirli bir yüzdesini geçemez. Bu tek cümle, üç yıllık toplam sahip olma maliyetinizi öngörülebilir hâle getirir. Maliyet kalemlerinin tamamını nasıl hesaplayacağınızı fiyatlandırma sayfamızda ayrıca ele aldık.
2. SLA kademeleri: müdahale mi, çözüm mü?
Sözleşmelerde en sık karıştırılan iki kavram müdahale süresi ve çözüm süresidir. Müdahale süresi, talebinizin bir uzman tarafından ele alınmaya başlandığı ana kadar geçen süredir. Çözüm süresi ise sorunun fiilen giderildiği andır. Sözleşmede yalnızca müdahale süresi yazıyorsa, "dört saat" ifadesi size sistemin dört saatte açılacağını değil, dört saat içinde birinin telefonu açacağını taahhüt eder. Fark, üretimin durduğu bir sabahta belirleyicidir.
İkinci mesele kademelendirmedir. Bütün taleplerin aynı sürede karşılanmasını istemek hem gerçekçi değildir hem de fiyatı gereksiz yükseltir. Aşağıdaki gibi üç kademeli bir tablo, hem tedarikçi için uygulanabilir hem sizin için ölçülebilir olur.
| Kademe | Tanım | Müdahale | Geçici çözüm | Örnek |
|---|---|---|---|---|
| Kritik | Sistem çalışmıyor, üretim etkileniyor | 2 saat (mesai dışı dâhil) | Aynı gün | Uygulama açılmıyor, veritabanı erişilemiyor |
| Yüksek | Bir modül çalışmıyor, iş yürümüyor | 4 saat (mesai içi) | 2 iş günü | Doküman onay akışı ilerlemiyor |
| Normal | Hata var ama alternatif yolla iş yürüyor | 1 iş günü | 10 iş günü | Rapor çıktısında sütun hatası |
| Talep | Yeni rapor, alan ya da yetki isteği | 2 iş günü | Takvim birlikte belirlenir | Yeni tedarikçi karne formülü |
Tabloyu sözleşme eki yapın ve her kademe için ölçüm yönteminin de yazılmasını isteyin: süre ne zaman başlıyor, mesai dışı bildirim hangi kanaldan yapılıyor, aşılırsa ne oluyor? Yaptırım maddesi olmayan bir SLA yalnızca iyi niyet beyanıdır. Genelde kullanılan yaptırım, aşım başına yıllık bakım bedelinden orantılı indirim yapılmasıdır.
Üçüncü ayrıntı çalışma saatleridir. Üç vardiya çalışan bir fabrikada mesai içi desteğin 08:00-18:00 olarak tanımlanması, gece vardiyasını tamamen kapsam dışında bırakır. Gece sistem durduğunda ne olacağını sözleşmede görmek istiyorsanız, kritik kademe için mesai dışı erişim numarası ve nöbetçi mühendis düzenini yazılı isteyin. Bu ek bir bedel getirebilir; getirsin, ama sürpriz olmasın.
3. Sürüm yükseltme kapsamı
Sözleşmede açıkça yazmıyorsa, sürüm yükseltmelerinin bakım bedeline dâhil olduğunu varsaymayın. Yaygın model şudur: ara sürümler dâhildir, ana sürümler ayrı fiyatlandırılır. İstenecek ifade nettir: bakım süresi boyunca yayımlanan tüm ana ve ara sürümler ek bedel olmaksızın kullanım hakkı kapsamındadır. Bunun yanına ikinci bir cümle daha ekletin: yükseltme çalışmasının kimin adam-günüyle yapılacağı ve test ortamının kim tarafından kurulacağı.
Kalite tarafını doğrudan ilgilendiren bir ayrıntı da şu: yükseltme sonrası geçerlilik kontrolü kimin sorumluluğunda? Doküman onay akışınız, elektronik imza mekanizmanız ve yetki matrisiniz yükseltme sonrası aynı davranmıyorsa, bu kalite sisteminizde bir uygunsuzluk demektir. Test senaryolarınızı önceden hazırlayıp yükseltme sonrası çalıştırın; doküman yönetimi tarafında en az beş senaryo yeterlidir.
Destek talebini WhatsApp'tan ya da tanıdığınız mühendisin cep telefonundan açmak, rahat göründüğü için herkesin düştüğü tuzak. O talebin kaydı hiçbir yerde tutulmaz, SLA sayacı başlamaz ve yıl sonunda tedarikçi performansını ölçmek için elinizde tek bir veri kalmaz. Talepleri her zaman sözleşmede tanımlı kanaldan açın; acil durumda telefon edeceksiniz, ama telefondan sonra aynı talebi resmi kanala da yazın.
4. Özelleştirme sonrası destek
Bu madde, sahada en çok tartışma çıkaran maddedir. Tedarikçi sizin için özel bir rapor ya da ek alan geliştirir; altı ay sonra bir hata çıkar ve cevap gelir: "Bu özel geliştirme, standart destek kapsamı dışında." Oysa geliştirmeyi yapan da aynı firmadır. Sözleşmeye şu ayrımı koydurun: tedarikçi tarafından yapılan her özelleştirme, standart üründe olduğu gibi garanti ve destek kapsamındadır; yalnızca müşteri ya da üçüncü taraf tarafından yapılan müdahaleler kapsam dışıdır.
Bir de kapsam dışı kalemlerin listesini yazılı isteyin. Tipik olarak kapsam dışıdır: kullanıcı hatasından doğan veri düzeltmeleri, işletim sistemi ve veritabanı lisansları, ağ ve donanım arızaları, sizin yaptığınız veritabanı müdahaleleri. Bu liste sözleşmede yoksa, her destek talebinde kapsam tartışması yaşarsınız.
Özelleştirmelerin sürüm yükseltmelerinde ne olacağını da aynı maddeye bağlayın. Standart ürüne yeni bir sürüm geldiğinde, sizin için yapılmış özel alan ve raporların yeni sürümle uyumlu hâle getirilmesi kimin işi? Cevap yazılı değilse, her yükseltmede ayrı bir teklif alırsınız ve bir süre sonra yükseltme yapmaktan vazgeçersiniz. Güncel sürümde kalmayan bir kalite sistemi ise birkaç yıl içinde destek dışı kalır.
5. Veri iadesi: format ve süre
"Verileriniz her zaman sizindir" cümlesi tek başına bir taahhüt değildir. Sözleşmede teslim edilecek şeyin ne olduğu format adıyla yazmalıdır: çalışır durumda bir veritabanı yedeği, eklerin klasör hiyerarşisi bozulmadan tamamı ve tabloların hangi veriyi tuttuğunu gösteren bir şema dökümü. Bu üçü olmadan başka bir sisteme taşınamazsınız. Teslim süresi de gün cinsinden belirtilmeli; 5 iş günü makul bir taahhüttür.
Şirket içi kurulumlarda bu madde büyük ölçüde anlamını yitirir, çünkü veritabanı zaten sizin sunucunuzdadır. Bulut ve abonelik modellerinde ise bu madde sözleşmenin en kritik satırıdır. Yedekleme ve erişim tarafındaki teknik ayrıntıları veri güvenliği yazımızda ayrıntılı anlattık.
IATF 16949 madde 7.5.3.2.1, kayıtların saklama sürelerini tanımlamanızı ve bu süre boyunca kayıtların okunabilir kalmasını ister; PPAP kayıtları için beklenti ürün ömrü artı bir takvim yılıdır. Bu şart, bakım sözleşmenizin fesih maddesiyle doğrudan çakışır. Aboneliğiniz bittiğinde on yıllık PPAP arşivinize erişemiyorsanız, kayıt saklama şartınızı karşılamıyorsunuz demektir. Denetçi yazılım sözleşmesini okumaz ama kaydı ister; kayıt yoksa bulgu yazar.
Veri teslimini yılda bir kez fiilen deneyin, sözleşme bitmesini beklemeyin. Tedarikçiden test amaçlı bir teslim isteyin ve gelen dosyaları kendi ortamınızda açmayı deneyin. Bir kez denenmemiş bir teslim taahhüdü, bir kez denenmemiş yedek kadar risklidir.
6. Fesih sonrası okuma hakkı
Yukarıdaki denetim riskini kapatan tek şey, sözleşmeye eklenecek bir okuma hakkı maddesidir. Önerdiğimiz kurgu şu: fesih tarihinden itibaren en az 90 gün boyunca sistem salt okunur modda açık kalır ve aynı süre içinde tam veri teslimi yapılır. Doksan gün, arşivi taşıyıp yeni sistemde doğrulamak için yeterli bir süredir. Bu maddeyi kabul etmeyen bir tedarikçiyle çalışıyorsanız, arşivinizin yedeğini her yıl kendi diskinize almayı prosedür hâline getirin.
Fesih maddesinde ikinci bir ayrıntı da bildirim süresidir. Yenilemeyi düşünmüyorsanız ne kadar önce yazılı bildirmeniz gerektiğine bakın; 30 günlük bildirim süresi normaldir, 90 günü aşan süreler sizi bir yıl daha bağlar. Sözleşmenin kendiliğinden yenilenip yenilenmediğini de kontrol edin.
Tedarikçi performansını ölçmek
Kalite biriminde tedarikçilerimizi her yıl karneliyoruz; yazılım tedarikçisini karnelemeyi ise çoğu firma akıl etmiyor. Oysa aynı mantık burada da işler. Yıl boyunca açılan destek taleplerini kademe, açılış tarihi, kapanış tarihi ve SLA aşımı olacak şekilde basit bir tabloda tutun. On iki ay sonra elinizde şu üç sayı olur: toplam talep sayısı, ortalama kapanma süresi ve aşım oranı.
Bu üç sayı, yenileme görüşmesinde elinizdeki tek gerçek koz. "Destek kötü" cümlesinin pazarlıkta hiçbir ağırlığı yok; "geçen yıl açtığımız 41 talebin 9'unda SLA aşıldı" cümlesinin var. Aynı tablo, yönetim gözden geçirme toplantısına da girdi olur ve tedarikçi değerlendirme sürecinizin kapsamını doğal biçimde genişletir.
Yazılım bakım destek sözleşmesi imza öncesi son kontrol
Sözleşme dosyasını kapatmadan önce şu altı cümleyi metinde tek tek arayın: yıllık artış üst sınırı, kademeli SLA tablosu ve yaptırımı, tüm sürümlerin dâhil olduğu ifadesi, tedarikçi özelleştirmelerinin destek kapsamında olduğu ifadesi, veri teslim formatı ve süresi, fesih sonrası okuma hakkı. Altısı da metinde varsa sözleşme sağlamdır. Biri bile eksikse, o eksik madde bir gün karşınıza çıkar.
PaKalite'de bu maddelerin çoğu kendiliğinden çözülüyor, çünkü kurulum sizin sunucunuza yapılıyor ve veritabanı sizde kalıyor; destek kesilse bile sistem çalışmaya devam ediyor. Yine de tercihiniz hangi ürün olursa olsun, teklif aşamasında seçim sırasında sorulacak 20 soruyu yanınıza alın ve destek başlığındaki cevapları yazılı isteyin. Sözleşmenin sizi koruduğu tek an, işlerin kötü gittiği andır. İyi yazılmış bir yazılım bakım destek sözleşmesi, o anı yönetilebilir bir sürece çevirir.